Chip development method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of chip development, in particular to a chip development method and device, electronic equipment and a storage medium. For the independent hardware sub-module corresponding to the target chip, monitoring whether at least one personal remote code branch corresponding to the independent hardware sub-module is updated or not; if the personal remote code branch corresponding to the independent hardware sub-module is updated, acquiring an updated code branch corresponding to the updated personal remote code branch; and performing code detection on the independent hardware sub-module based on the updated code branch to generate an initial test result. According to the method, errors can be found in the early stage, developers can quickly repair the errors, the errors are prevented from spreading in a system, the development process is accelerated, the overall quality of chip development projects is improved, and the later reworking cost is reduced. Therefore, problems can be found in time in the chip development process, and the chip development efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of chip development, and particularly to a chip development method, apparatus, electronic device, and storage medium. Background Art

[0002] In the current field of chip development, with the continuous improvement of chip integration and the increasing complexity of functions, the code scale has increased exponentially, and the effective monitoring of code quality has become a key link in ensuring the progress and performance of chip development. However, during the chip development process, various problems often occur during the code verification stage at the top layer or module layer. These problems cannot be discovered and fixed in a timely manner, directly resulting in an extended chip development cycle, reduced development efficiency, postponed product listing time, weakened market competitiveness of enterprises, and thus severely restricted the efficient development of the chip development industry.

[0003] Therefore, how to discover problems in a timely manner during the chip development process and thus improve the chip development efficiency has become an urgent problem to be solved. Summary of the Invention

[0004] In view of this, the present invention provides a chip development method, apparatus, electronic device, and storage medium to solve the problem of how to discover problems in a timely manner during the chip development process and thus improve the chip development efficiency.

[0005] In a first aspect, the present invention provides a chip development method, the method comprising:

[0006] Monitoring whether at least one personal remote code branch corresponding to an independent hardware sub-module of a target chip is updated;

[0007] If the personal remote code branch corresponding to the independent hardware sub-module is updated, obtaining the updated code branch corresponding to the updated personal remote code branch;

[0008] Performing code detection on the independent hardware sub-module based on the updated code branch to generate an initial test result.

[0009] The chip development method provided by the embodiments of this application monitors whether at least one personal remote code branch corresponding to an independent hardware sub-module of a target chip is updated, so as to timely detect whether each personal remote code branch corresponding to the independent hardware sub-module is updated. In addition, it can accurately locate the update of the independent hardware sub-module caused by the specific code changes of each personal remote code branch. For example, when a problem occurs in the hardware sub-module, it can be quickly traced back to which developer's code update caused it, which is convenient for quickly troubleshooting and solving problems, improving the development team's control ability over code changes, reducing the time for error troubleshooting, and improving development efficiency. It solves the problem that in the traditional method, it is difficult to accurately track the impact of each developer's code changes on the hardware sub-module. If the personal remote code branch corresponding to the independent hardware sub-module is updated, the updated code branch corresponding to the updated personal remote code branch is obtained. Once it is detected that the personal remote code branch is updated, the electronic device will automatically obtain the updated code branch without manual intervention. This greatly improves work efficiency, especially in large-scale chip development projects, which involve numerous independent hardware sub-modules and personal remote code branches. Manually obtaining the updated code branch is not only time-consuming and laborious but also prone to omissions or errors. Code detection is performed on the independent hardware sub-module based on the updated code branch to generate an initial test result. This helps to timely discover potential problems in the code, such as syntax errors, logical errors, memory leaks, etc., before the code is integrated into the main project. By discovering and solving these problems early, the workload in the subsequent testing and debugging phases can be reduced, and the development cost and time can be lowered. In addition, in chip development, the code update of the independent hardware sub-module may affect the compatibility with other modules. By detecting the updated code branch, these compatibility problems can be discovered in advance and repaired in a timely manner. For example, the new code may introduce new interfaces or modify the parameters of existing interfaces. Through code detection, it can be determined whether these changes will cause problems in the interaction with other modules.

[0010] In an alternative implementation, code detection is performed on the independent hardware sub-module based on the updated code branch to generate an initial test result, including:

[0011] Detect whether there is a conflict between the updated code branch and the target remote code branch corresponding to the independent hardware sub-module; the target remote code branch is used to represent the code sum of each personal remote code branch in the independent hardware sub-module;

[0012] If there is no conflict between the updated code branch and the target remote code branch, the updated code branch and the target remote code branch are merged to obtain a target merge branch;

[0013] Perform test case detection on the target merge branch to generate an initial test result.

[0014] The chip development method provided by the embodiments of this application detects whether there are conflicts between the updated code branch and the target remote code branch corresponding to the independent hardware sub-module. In the scenario of multi-person collaborative development of independent hardware sub-modules, different developers may modify different personal remote code branches simultaneously. Detecting whether there are conflicts between the updated code branch and the target remote code branch can discover potential code conflict problems in advance. For example, two developers may modify the same line of code or related code logic simultaneously. If the code is directly merged without conflict detection, it will lead to code chaos and generate errors that are difficult to debug. Through conflict detection, developers can be reminded in time to resolve conflicts, ensuring the consistency and integrity of the code. In addition, the code of independent hardware sub-modules usually has a complex logical structure, and there may be interdependencies between different personal remote code branches. Conflict detection helps to ensure the coherence between the updated code branch and the existing code logic. When the updated code branch introduces new functions or modifies existing functions, detecting conflicts can find out whether the original code logic will be damaged, avoiding function abnormalities caused by code merging. If there are no conflicts between the updated code branch and the target remote code branch, the updated code branch and the target remote code branch are merged to obtain the target merged branch. This merging process greatly reduces the workload of manually merging code and improves the efficiency of code merging. Especially in large-scale chip development projects, involving a large number of personal remote code branches and frequent code updates, manual code merging is prone to errors and takes a long time. Automatic merging can avoid these problems. In addition, the merging process follows strict rules and algorithms, and can accurately integrate the updated code branch into the target remote code branch. Compared with manual merging, automatic merging can reduce human errors and ensure the accuracy of the merging result. At the same time, the system can record the detailed information of the merging process for subsequent auditing and tracing. Finally, test case detection is performed on the target merged branch to generate the initial test results. This means that the test is based on the complete merged code, and can more comprehensively verify the functions and performance of the code. Compared with testing the updated code branch and the target remote code branch separately, testing the merged code can discover new problems that may be introduced during the code merging process, such as compatibility problems and logical conflicts. By performing test case detection in time after code merging, potential problems can be discovered before the code is integrated into the main project. This can avoid introducing problematic code into subsequent development and testing phases, reducing the cost and time of problem fixing. For example, if it is found that a certain function does not work properly in the merged code, developers can locate and fix the problem in time, rather than discovering the problem during the integrated system testing. The above method defines clear code conflict detection, merging, and testing processes, making the development process more standardized and controllable. All code updates need to go through conflict detection and merging operations, and then unified test case detection is performed to ensure that the code quality meets the requirements.This standardized process helps to improve the collaboration efficiency of the team and reduce problems caused by non-standardized development processes.

[0015] In an alternative embodiment, the method further includes:

[0016] If the initial test result indicates that the code detection of the independent hardware sub-module is successful, then it is detected whether there is at least one upper-layer hardware subsystem corresponding to the independent hardware sub-module;

[0017] If there is at least one upper-layer hardware subsystem for the independent hardware sub-module, then based on the target merge branch, code detection is performed on each upper-layer hardware subsystem to generate a target detection result.

[0018] For the chip development method provided by the embodiments of the present application, if the initial test result indicates that the code detection of the independent hardware sub-module is successful, then it is detected whether there is at least one upper-layer hardware subsystem corresponding to the independent hardware sub-module; if there is at least one upper-layer hardware subsystem for the independent hardware sub-module, then based on the target merge branch, code detection is performed on each upper-layer hardware subsystem to generate a target detection result. When the code update of the independent hardware sub-module passes the initial test, code detection is further performed on its upper-layer hardware subsystem, which can verify the compatibility between the updated sub-module code and the upper-layer system. For example, the independent hardware sub-module may be responsible for data acquisition, while the upper-layer hardware subsystem is responsible for data processing and analysis. The update of the sub-module code may change the format or frequency of data output. By detecting the upper-layer system, it can be timely found whether this change will cause the upper-layer system to be unable to process data correctly, thus ensuring the normal operation of the entire system. In addition, by detecting the upper-layer hardware subsystem, it can be ensured that the updated sub-module code will not cause the loss of functions or abnormalities in the upper-layer system. For example, the code update of the independent hardware sub-module may introduce new functions, but this new function may conflict with some functions of the upper-layer system. By detecting the upper-layer system, these problems can be timely found and solved. Finally, code detection of the upper-layer hardware subsystem can detect problems that may be caused by the code update of the independent hardware sub-module in advance, and can be repaired when the problems are relatively simple. Compared with discovering problems during the entire system integration test or after product delivery, early discovery of problems can greatly reduce the costs of debugging and maintenance. For example, when problems are discovered during the system integration test stage, it may be necessary to troubleshoot and debug multiple modules and systems. However, by detecting the upper-layer system in a timely manner after the code update of the sub-module, the problem location can be more accurate, reducing the workload and time of debugging. This enhances the robustness of chip development.

[0019] In an alternative embodiment, if there is at least one upper-layer hardware subsystem for the independent hardware sub-module, then based on the target merge branch, code detection is performed on each upper-layer hardware subsystem to generate a target detection result, including:

[0020] For each upper-layer hardware subsystem, obtain other hardware submodules on which the upper-layer hardware subsystem depends, excluding independent hardware submodules.

[0021] Obtain the latest version code corresponding to the other hardware submodules.

[0022] Based on the target merge branch and the latest version code corresponding to the other hardware submodules, perform test case detection on the upper-layer hardware subsystem to generate a first test result.

[0023] Generate a target detection result according to the first test result.

[0024] The chip development method provided by the embodiments of the present application, for each upper-layer hardware subsystem, obtains other hardware submodules on which the upper-layer hardware subsystem depends, excluding independent hardware submodules. Obtain the latest version code corresponding to the other hardware submodules. Based on the target merge branch and the latest version code corresponding to the other hardware submodules, perform test case detection on the upper-layer hardware subsystem to generate a first test result. By obtaining the latest version code of the other hardware submodules and performing joint testing with the target merge branch, it is closer to the actual operating environment of the system, making the first test result generated by the test case detection more accurate and reliable. Compared with only testing the update of a single hardware submodule, more problems hidden in complex hardware interactions can be discovered, providing stronger guarantee for the quality of the system. In addition, potential incompatibility problems can be discovered in advance, avoiding software failures caused by hardware updates after system integration or going online, and improving the stability and reliability of the system. Generate a target detection result according to the first test result, so as to ensure the accuracy of the generated target detection result.

[0025] In an alternative embodiment, generating a target detection result according to the first test result includes:

[0026] Obtain the latest version code corresponding to the independent hardware submodule; the latest version code is the code with a version number that has been successfully tested before the update of the independent hardware submodule and is currently in normal use.

[0027] Based on the latest version code corresponding to the independent hardware submodule and the latest version code corresponding to the other hardware submodules, perform test case detection on the upper-layer hardware subsystem to generate a second test result.

[0028] Generate a target detection result according to the first test result and the second test result.

[0029] The chip development method provided by the embodiments of the present application obtains the latest version code corresponding to the independent hardware sub-module; performs test case detection on the upper-layer hardware subsystem according to the latest version code corresponding to the independent hardware sub-module and the latest version codes corresponding to other hardware sub-modules, and generates a second test result. According to the first test result and the second test result, a target detection result is generated.

[0030] The above method can compare and analyze the first test result and the second test result, and can quantify the changes brought by the corresponding target merge branch of the independent hardware sub-module to the performance, functions, etc. of the upper-layer hardware subsystem. For example, it can determine whether the response time of the upper-layer hardware subsystem increases after the update, whether the execution efficiency of certain functions decreases, etc., which helps the development team comprehensively understand the impact degree of the update, so as to make more reasonable decisions, such as whether to adjust the target merge branch or adaptively optimize the upper-layer hardware subsystem. For example, if the upper-layer hardware subsystem runs normally in the second test, but a specific function is abnormal in the first test, then it can be determined that the abnormality is caused by the update of the independent hardware sub-module, providing a clear direction for subsequent problem fixing and optimization. In addition, by comparing the first test result and the second test result, it can be detected whether the update introduces new security vulnerabilities or risks. During the development process, if such a comparison test is not performed, unnecessary modifications and rework may be carried out due to inaccurate evaluation of the impact of the independent hardware sub-module update. By comparing the first test result and the second test result, the development team can more accurately judge whether the upper-layer hardware subsystem needs to be adjusted and the scope and degree of the adjustment, avoid excessive modification, thereby reducing the waste of development time and resources and improving the development efficiency.

[0031] In an alternative embodiment, the method further includes:

[0032] For each upper-layer hardware subsystem, if the self-system code corresponding to the upper-layer hardware subsystem is updated to generate self-system update code, the latest version codes corresponding to the independent hardware sub-modules relied on by the upper-layer hardware subsystem are obtained; wherein, the upper-layer hardware subsystem runs based on the self-system update code and the independent hardware sub-modules relied on.

[0033] Based on the self-system update code and the latest version codes corresponding to the independent hardware sub-modules, test case detection is performed on the upper-layer hardware subsystem.

[0034] The chip development method provided by the embodiments of this application, for each upper-layer hardware subsystem, if the self-system code corresponding to the upper-layer hardware subsystem is updated to generate self-system update code, then obtain the latest version code corresponding to each independent hardware sub-module on which the upper-layer hardware subsystem depends; based on the self-system update code and the latest version code corresponding to each independent hardware sub-module, perform test case detection on the upper-layer hardware subsystem, so as to ensure the compatibility between software and hardware. When a problem is found during testing, since it is clear that it occurs under the software's own update and the current state of the hardware, developers can quickly locate the root cause of the problem, whether it is an error introduced by the software update or a problem with the interaction with the hardware. For example, if a data error occurs during testing, by analyzing the self-system update code and the latest version code corresponding to the hardware sub-module, it can be quickly determined whether it is a software algorithm error or a hardware data transmission exception, so as to solve the problem targeted, reduce the development cycle, and improve the development efficiency. In addition, by performing detection based on the self-system update code and the latest version code corresponding to each hardware sub-module, more comprehensive and strict quality control is carried out on the upper-layer hardware subsystem. This helps to discover problems such as logical errors and improper handling of boundary conditions in software updates, ensure that the software can work properly in the new hardware environment, improve the software quality, and lay a foundation for the reliability of the entire chip system.

[0035] In an alternative embodiment, the method further includes:

[0036] If the target detection result indicates that the detection is passed, then detect whether there is at least one upper-layer hardware system corresponding to each upper-layer hardware subsystem;

[0037] If there is at least one upper-layer hardware system corresponding to each upper-layer hardware subsystem, then based on the target merge branch, perform code detection on each upper-layer hardware system to generate a process detection result;

[0038] Until, based on the target merge branch, perform test case detection on the top-level system corresponding to the target chip to generate a final detection result.

[0039] The chip development method provided by the embodiment of the present application, if the target detection result characterizes that the detection is passed, then detects whether there is at least one upper-level hardware system corresponding to each upper-level hardware subsystem. If there is at least one upper-level hardware system corresponding to each upper-level hardware subsystem, then based on the target merge branch, the code detection of each upper-level hardware system is performed to generate a process detection result. Until based on the target merge branch, the top-level system corresponding to the target chip is tested for test cases to generate the final detection result. It is realized that from the upper-level hardware subsystem to the top-level system, detection is performed based on the target merge branch in sequence, and the adaptation of the target merge branch in the entire chip development system can be fully verified. When the final detection result shows that there is an error, since it is gradually tested from the upper-level hardware subsystem to the top-level system, the interaction link between the hardware system at which the error occurs and the target merge branch can be accurately located according to the process detection result and the final detection result. It is realized that the level where the problem is located is quickly determined, and repeated testing of other normal levels is avoided, which saves test time and resources and improves development efficiency. The risk of the system integration stage is greatly reduced, and the success rate of integration and the stability of the system are improved.

[0040] In a second aspect, the present invention provides a chip development device, the device comprising:

[0041] A monitoring module, for monitoring whether at least one personal remote code branch corresponding to the independent hardware sub-module corresponding to the target chip is updated;

[0042] An acquisition module, used for acquiring an update code branch corresponding to the updated personal remote code branch if the personal remote code branch corresponding to the independent hardware sub-module is updated;

[0043] The detection module is used to perform code detection on independent hardware sub-modules based on the updated code branch to generate initial test results.

[0044] The chip development device provided by the embodiments of the present application monitors whether at least one personal remote code branch corresponding to an independent hardware sub-module of a target chip is updated, so as to timely detect whether each personal remote code branch corresponding to the independent hardware sub-module is updated. In addition, it can accurately locate the updates of the independent hardware sub-module caused by the specific code changes of the R & D personnel corresponding to each personal remote code branch. For example, when a problem occurs in the hardware sub-module, it can be quickly traced back to which R & D personnel's code update caused it, which is convenient for quickly troubleshooting and solving problems, improving the development team's control ability over code changes, reducing the time for error troubleshooting, and improving development efficiency. It solves the problem that it is difficult to accurately track the impact of each R & D personnel's code changes on the hardware sub-module in the traditional way. If the personal remote code branch corresponding to the independent hardware sub-module is updated, the updated code branch corresponding to the updated personal remote code branch is obtained. Once it is detected that the personal remote code branch is updated, the electronic device will automatically obtain the updated code branch without manual intervention. This greatly improves work efficiency, especially in large-scale chip development projects, which involve numerous independent hardware sub-modules and personal remote code branches. Manually obtaining the updated code branch is not only time-consuming and laborious, but also prone to omissions or errors. Code detection is performed on the independent hardware sub-module based on the updated code branch to generate an initial test result. This helps to timely discover potential problems in the code, such as syntax errors, logical errors, memory leaks, etc. before the code is integrated into the main project. By discovering and solving these problems early, the workload in the subsequent test and debugging phases can be reduced, and the development cost and time can be lowered. In addition, in chip development, the code update of the independent hardware sub-module may affect the compatibility with other modules. By detecting the updated code branch, these compatibility problems can be discovered in advance and repaired in a timely manner. For example, the new code may introduce new interfaces or modify the parameters of existing interfaces, and code detection can find out whether these changes will cause problems in the interaction with other modules.

[0045] In a third aspect, the present invention provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to execute the chip development method according to the first aspect or any corresponding embodiment thereof.

[0046] In a fourth aspect, the present invention provides a computer-readable storage medium, on which computer instructions are stored, and the computer instructions are used to cause a computer to execute the chip development method according to the first aspect or any corresponding embodiment thereof.

[0047] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to execute the chip development method according to the first aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0049] Figure 1 is a schematic flowchart of a chip development method according to an embodiment of the present invention;

[0050] Figure 2 is a schematic diagram of the division of target chip business modules according to an embodiment of the present invention;

[0051] Figure 3 is a schematic diagram of code repository management according to an embodiment of the present invention;

[0052] Figure 4 is a schematic flowchart of another chip development method according to an embodiment of the present invention;

[0053] Figure 5 is a schematic diagram of personal remote code branch management according to an embodiment of the present invention;

[0054] Figure 6 is a schematic flowchart of the process from personal creation of a remote branch to code verification and result synchronization according to an embodiment of the present invention;

[0055] Figure 7 is an interaction schematic diagram of the process from personal creation of a remote branch to code verification and result synchronization according to an embodiment of the present invention;

[0056] Figure 8 is an iteration schematic diagram of an independent hardware sub-module according to an embodiment of the present invention;

[0057] Figure 9 is an iteration schematic diagram of upper-layer hardware subsystem requirements according to an embodiment of the present invention;

[0058] Figure 10 is a schematic flowchart of the process for obtaining the final detection result according to an embodiment of the present invention;

[0059] Figure 11 is a structural block diagram of a chip development device according to an embodiment of the present invention;

[0060] Figure 12It is a schematic diagram of the hardware structure of the electronic device according to an embodiment of the present invention. Detailed implementation manners

[0061] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are some but not all of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0062] In the current field of chip development, with the continuous improvement of chip integration and the increasing complexity of functions, the code scale has increased exponentially, and the effective monitoring of code quality has become a key link in ensuring the chip development progress and performance. However, there are many problems to be solved urgently in the existing chip code quality monitoring methods, which seriously restrict the efficient development of the chip development industry. The specific problems are as follows:

[0063] 1. During the chip development process, code quality needs to be detected at multiple key nodes. Currently, it mainly relies on the manual operations of the development and verification personnel of each module. This not only requires a large number of professional personnel to be invested, but also as the project scale expands, the labor cost rises rapidly, becoming a heavy burden on chip development enterprises.

[0064] 2. During the code verification stage at the top layer or module layer, various problems often occur. Some modules have code defects during the early development. Since the verification personnel fail to perform regression testing in a timely manner, or the local code is inconsistent with the remote repository code during regression, these problems cannot be discovered and fixed in a timely manner, directly resulting in an extended chip development cycle, a postponed product launch time, and a weakened market competitiveness of the enterprise.

[0065] 3. Verification personnel are used to developing and verifying code locally, but fail to synchronize the local code to the remote server in a timely manner. This makes it difficult for other developers to obtain the latest code, and they have to frequently consult the module development and verification personnel, resulting in a high degree of coupling between developers, seriously affecting the team collaboration efficiency, and hindering the rapid iteration and optimization of the code.

[0066] 4. When multiple subsystems or IPs perform version regression, there are often situations of insufficient service resources, and there are also problems of regression redundancy. For example, the verification case regression list of a certain IP may be repeatedly triggered by the design or verification personnel multiple times, but there is a lack of a reasonable business regression planning mechanism, resulting in resource waste and low development efficiency.

[0067] 5. In actual project development, a module is often developed by multiple developers working together, which can easily lead to code conflicts. Moreover, there is currently a lack of an effective mechanism to track incremental code, making it difficult for developers to quickly locate and resolve conflicts, further affecting the development progress and code quality.

[0068] 6. The prior art cannot effectively analyze and monitor the latest code quality data, such as current code defect data. At the same time, it is also impossible to directly obtain the overall usage frequency of the verification regression server and the current regression strength, resulting in the inability to accurately evaluate and plan the dynamic allocation of server resources and regression strength, and it is difficult to achieve the optimal utilization of resources.

[0069] 7. The amount of data generated during the chip code verification regression is huge, usually reaching the TB level, which brings great pressure to the server storage. The frequent problem of disk shortage will cause the entire system process to exit abnormally. In addition, when multiple modules are regressed, a large number of concurrent processes will probabilistically cause the system process to be abnormal, seriously affecting the stability of the development environment.

[0070] 8. During the chip development process, it is impossible to dynamically evaluate the current development pressure of developers, making it difficult for project managers to reasonably allocate tasks and resources, which is not conducive to the long-term stable development of the team and the smooth progress of the project.

[0071] Therefore, how to timely discover problems during the chip development process and then improve the chip development efficiency has become an urgent problem to be solved.

[0072] It should be noted that the method for chip development provided by the embodiments of the present application may be executed by a chip development device. The chip development device may be implemented as part or all of an electronic device through software, hardware, or a combination of software and hardware. Among them, the electronic device may be a server or a terminal. Among them, the server in the embodiments of the present application may be a single server or a server cluster composed of multiple servers. The terminal in the embodiments of the present application may be other intelligent hardware devices such as a smart phone, a personal computer, a tablet computer, a wearable device, and a smart robot. In the following method embodiments, the execution entity is taken as an example of an electronic device for description.

[0073] According to an embodiment of the present invention, an embodiment of a chip development method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings may be executed in a computer system such as a set of computer executable instructions. And although the logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than here.

[0074] In this embodiment, a chip development method is provided, which can be used for the above-mentioned electronic device. Figure 1is a flowchart of a chip development method according to an embodiment of the present invention. As Figure 1 shown, the process includes the following steps:

[0075] Step S101: For the independent hardware sub-module corresponding to the target chip, monitor whether at least one personal remote code branch corresponding to the independent hardware sub-module is updated.

[0076] Specifically, the electronic device can obtain the personal remote code branches corresponding to each developer included in the independent hardware sub-module based on a preset operation command line.

[0077] Exemplarily, execute the git branch -r command, which will list all branches in the remote repository corresponding to the independent hardware sub-module. The electronic device will obtain the branch list information from the remote repository and display personal remote code branches corresponding to each developer, such as "origin / feat_ci_developer1_module_dev", "origin / feat_ci_developer2_module_dev", etc. Through these branch names, different developers' development branches can be identified. If you want to obtain a specific developer's personal remote code branch, such as "origin / feat_ci_Lisi_independent hardware sub-module_dev", use the command "git checkout -b local branch name origin / feat_ci_Lisi_independent hardware sub-module_dev" on the device terminal. This will create a branch named "local branch name" locally and synchronize the code of the remote branch origin / feat_ci_Lisi_independent hardware sub-module_dev to the local, facilitating developers to develop, test, and manage locally.

[0078] It should be noted that each developer can update the personal remote code branch in their own corresponding local area, and after the update, it can be uploaded to the personal remote code branch corresponding to the developer in the remote electronic device (i.e., the electronic device in the present application).

[0079] For the personal remote code branches corresponding to each developer, the electronic device can periodically compare the current code in the personal remote code with the historical code at the previous moment to detect whether the personal remote code branch is updated. If the current code is different from the historical code, it is determined that the personal remote code branch is updated; if the current code is the same as the historical code, it is determined that the personal remote code branch is not updated.

[0080] Exemplarily, the electronic device can utilize a scheduled task (such as Cron Job in the Linux system) to periodically execute the git pull command to pull the latest current code from the remote repository corresponding to the independent hardware sub-module. After each pull, the local branch is compared through the git diff command, that is, the historical code and the branch status after the pull. If there are differences, it indicates that the personal remote code branch has been updated. For example, set the Cron Job to execute the script every 15 minutes, and the script content is git pull && git diff HEAD@{1} HEAD, where HEAD@{1} represents the version of the previous commit, and HEAD represents the current version. Whether there is an update is determined by comparing the differences between the two.

[0081] Exemplarily, on a Git service platform (such as GitHub, GitLab), a Webhook can be configured. When there is an update operation (such as code push, merge, etc.) on the personal remote code branch, the Git service platform will send an HTTP request to the specified URL of the electronic device. After the receiving program running on the electronic device receives the request, it parses the request content to confirm the updated branch. For example, add a Webhook in the "Settings" - "Webhooks" of the GitHub repository, and specify the URL of the Flask application running on the electronic device as the receiving address. When there is an update, the Flask application can obtain the update information in a timely manner.

[0082] Step S102, if the personal remote code branch corresponding to the independent hardware sub-module is updated, obtain the updated code branch corresponding to the personal remote code branch where the update occurred.

[0083] Specifically. If the personal remote code branch corresponding to the independent hardware sub-module is updated, the electronic device can obtain the updated code branch of the personal remote code branch where the update occurred through command-line operations.

[0084] It should be noted that the target chip business module is divided as follows Figure 2 As shown, it can be divided into two types: independent entity (IP level), that is, independent hardware sub-module, and entity (sub-system level and SOC level) coupled with other modules. As Figure 3 shown, it is a schematic diagram of code repository management. Each entity above, that is, independent hardware sub-modules such as IP1 - IP6, sub-system TOP, SOC TOP, etc., corresponds to a respective code repository management.

[0085] Step S103, perform code detection on the independent hardware sub-module based on the updated code branch to generate an initial test result.

[0086] Specifically, the electronic device can perform code detection on the independent hardware sub-module according to the updated code branch and generate an initial test result.

[0087] This step will be introduced in detail below.

[0088] The chip development method provided by the embodiments of this application monitors whether at least one personal remote code branch corresponding to the independent hardware sub-module of the target chip is updated, so as to timely detect whether each personal remote code branch corresponding to the independent hardware sub-module is updated. In addition, it can accurately locate the update of the independent hardware sub-module caused by the specific R & D personnel code changes corresponding to each personal remote code branch. For example, when a problem occurs in the hardware sub-module, it can be quickly traced back to which R & D personnel's code update caused it, which is convenient for quickly troubleshooting and solving problems, improving the development team's control ability over code changes, reducing the error troubleshooting time, and improving the development efficiency. It solves the problem that it is difficult to accurately track the impact of each R & D personnel's code changes on the hardware sub-module in the traditional way. If the personal remote code branch corresponding to the independent hardware sub-module is updated, obtain the updated code branch corresponding to the updated personal remote code branch. Once it is detected that the personal remote code branch is updated, the electronic device will automatically obtain the updated code branch without manual intervention. This greatly improves work efficiency, especially in large-scale chip development projects, which involve numerous independent hardware sub-modules and personal remote code branches. Manually obtaining the updated code branch is not only time-consuming and laborious, but also prone to omissions or errors. Perform code detection on the independent hardware sub-module based on the updated code branch and generate an initial test result. This helps to timely discover potential problems in the code, such as syntax errors, logical errors, memory leaks, etc. before the code is integrated into the main project. By discovering and solving these problems early, the workload in the subsequent test and debugging phases can be reduced, and the development cost and time can be lowered. In addition, in chip development, the code update of the independent hardware sub-module may affect the compatibility with other modules. By detecting the updated code branch, these compatibility problems can be discovered in advance and repaired in time. For example, the new code may introduce new interfaces or modify the parameters of the existing interfaces. Through code detection, it can be found whether these changes will cause problems in the interaction with other modules.

[0089] In this embodiment, a chip development method is provided, which can be used for the above-mentioned electronic device. Figure 4 It is a flowchart of the chip development method according to the embodiments of the present invention, as Figure 4 shown, and this process includes the following steps:

[0090] Step S201, for the independent hardware sub-module corresponding to the target chip, monitor whether at least one personal remote code branch corresponding to the independent hardware sub-module is updated.

[0091] For this step, please refer to the introduction of step S101 above and will not be elaborated here.

[0092] Step S202: If the personal remote code branch corresponding to the independent hardware sub-module is updated, obtain the updated code branch corresponding to the updated personal remote code branch.

[0093] For this step, please refer to the introduction of step S102 above and will not be elaborated here.

[0094] Step S203: Perform code detection on the independent hardware sub-module based on the updated code branch to generate an initial test result.

[0095] Specifically, the above step S203 may include the following steps:

[0096] Step S2031: Detect whether there is a conflict between the updated code branch and the target remote code branch corresponding to the independent hardware sub-module.

[0097] Among them, the target remote code branch is used to represent the sum of the codes of each personal remote code branch in the independent hardware sub-module.

[0098] Specifically, the electronic device can switch to the target remote code branch and execute "git checkout target remote code branch name", and then pull the latest code from the remote repository. The command is git pull origin target remote code branch name. Here, origin is the default alias of the remote repository and can be modified according to the actual situation; the target remote code branch name should be replaced with the actual branch name.

[0099] Similarly, switch to the personal remote code branch, execute git checkout personal remote code branch name, and then pull the latest code "git pull origin personal remote code branch name", that is, pull the updated code branch.

[0100] Then, the electronic device attempts to merge the updated code branch into the target remote code branch locally to trigger the conflict detection mechanism.

[0101] The specific operation is as follows: First, switch back to the target remote code branch by executing "git checkout target remote code branch name", and then execute the merge command "git merge personal remote code branch name", that is, merge and update the code branch. If the electronic device outputs "Already up to date.", it indicates that the codes of the two branches are already the same, no merge is required, and there is no conflict. If it shows "Fast-forward", it means that the pointer of the target remote code branch can be directly moved forward to the position of the updated code branch. Usually, this situation also indicates that there is no conflict, and the updated code branch is an update based on the target remote code branch.

[0102] When the output of the electronic device contains the keyword "CONFLICT", it means that a conflict has occurred during the merge process. For example, the output may be "Auto-merging file path", and then it shows "CONFLICT (content conflict): Merge conflict in file path" and "Automatic merge failed; fix conflicts and then commit the result.", which indicates that there are conflicts in the modifications of the two branches in the file corresponding to the specified file path.

[0103] Optionally, if there is a conflict between the updated code branch and the target remote code branch, the electronic device can use the "git status" command to list all files in a conflict state. For example, the output may be "On branch target remote code branch name", and then it shows "You have unmerged paths." and the specific file paths of the conflicts, such as "both modified: file path 1", "both modified: file path 2", etc. For each conflict file, the electronic device can open it with a text editor to view. In the conflict file, git will use special markers to identify the conflict parts. For example, "<<< HEAD" represents the start position of the target remote code branch, "=======" is the separator line, and ">>>>>> personal remote code branch name" represents the end position of the personal remote code branch. The content between these two markers is the conflict part, and developers can clearly see the different modifications of the two branches.

[0104] Exemplarily, such as Figure 5As shown, it is a schematic diagram of code branch management. The origin / xp_top_dv_dev at the top of the figure is the main branch, that is, the target remote code branch, and other branches are all associated with it. There are multiple feature branches under the main code branch, such as origin / feat_ci_xiaom_npc-xxx_dev, origin / feat_ci_xiaoh_xvss-xxx_dev, origin / feat_ci_name-module_dev, etc. These are all personal remote code branches. The names of these feature branches usually contain the word "feat", indicating that they are branches for developing specific functions and may be related to specific projects or modules (such as xiaom_npc, xiaoh_xvss, name-module, etc.).

[0105] The lower left corner of the figure shows the relevant content of local code development management, with two branches: feat_ci_xiaom_npc-xxx_dev and xp_top_dv_dev. Among them, feat_ci_xiaom_npc-xxx_dev may be a branch pulled from the remote feature branch with the same name for local development, and xp_top_dv_dev may be a development branch corresponding to the local main branch. As can be seen from the arrows in the figure, each feature branch is derived from the main branch origin / xp_top_dv_dev for independent development of specific functions, and may be merged back into the main branch after development. The local branches feat_ci_xiaom_npc-xxx_dev and xp_top_dv_dev are associated with the remote branches. Local developers may write and test code on the local branches, and then push the code of the local branches to the remote branches, or pull the latest code from the remote branches to the local

[0106] Step S2032, if there is no conflict between the updated code branch and the target remote code branch, then merge the updated code branch and the target remote code branch to obtain the target merged branch.

[0107] Specifically, if there is no conflict between the updated code branch and the target remote code branch, the electronic device merges the updated code branch and the target remote code branch to obtain the target merged branch.

[0108] Step S2033, perform test case detection on the target merged branch to generate an initial test result.

[0109] Specifically, the electronic device can collect test cases related to the target merge branch from the test case library of the project. These test cases may cover multiple aspects such as functional testing, performance testing, compatibility testing, etc. Then, based on the updated content of the target merge branch, the electronic device analyzes the newly introduced functions or modified parts and writes corresponding new test cases. For example, if the update involves the optimization of an algorithm, test cases need to be written to verify whether the optimized algorithm achieves the expected effect. The collected and supplemented test cases are sorted and classified according to test types, priorities, etc. to ensure the integrity and executability of the test cases.

[0110] Next, the electronic device prepares corresponding test data according to the requirements of the test cases. The test data should be representative and cover various possible input situations. For example, if testing a data processing module, data files with different formats, sizes, and contents need to be prepared. The test data is deployed to the test environment to ensure that the test program can correctly access and use this data. At the same time, attention should be paid to the security and consistency of the data to avoid inaccurate test results due to data problems.

[0111] In the test environment, the electronic device can use a suitable compiler to compile the code of the target merge branch. If errors occur during the compilation process, the problems need to be located and solved in a timely manner to ensure that the code can be successfully compiled into an executable file. Then, the electronic device uses a test framework or tool to execute the test cases. Common test frameworks include JUnit (for Java), PyTest (for Python), etc. According to the classification and priority of the test cases, each test case is executed in turn. During the execution process, the execution results of each test case are recorded, including whether it passes, the execution time, error messages, etc. For example, use PyTest to execute the test cases of Python code. During the test execution process, various abnormal situations may occur, such as program crashes, timeouts, etc. When encountering abnormal situations, the abnormal information needs to be recorded in a timely manner, including the type of exception, the location where it occurred, the relevant log files, etc. According to the severity of the abnormal situation, it is decided whether to continue executing the subsequent test cases. If the abnormal situation affects the entire test process, the test may need to be suspended to troubleshoot and fix the problem.

[0112] Finally, the electronic device can count the execution results of all test cases, calculate the number of passed test cases, the number of failed test cases, and the pass rate. For example, a total of 100 test cases are executed, 90 of which pass and 10 fail, then the pass rate is 90%. The test results can be presented in the form of charts or reports to more intuitively understand the test situation.

[0113] For failed test cases, carefully analyze the reasons for failure. Possible reasons include code logic errors, unexpected input data, environment configuration issues, etc. Based on the analysis results of the failure reasons, locate the specific code location or problem point to provide a basis for subsequent repair work. Check the coverage of the test cases for the target merged branch code, including statement coverage, branch coverage, etc. Code coverage tools (such as Jacoco, Coverage.py, etc.) can be used to obtain code coverage information. If it is found that certain code areas are not covered by the test cases, corresponding test cases need to be added to improve the integrity of the test.

[0114] Exemplarily, as Figure 6 shown, it is a schematic diagram of the process from an individual creating a remote branch to code verification and result synchronization. The following is a specific introduction:

[0115] S1. An individual creates a personal remote branch feat_ci_xxx according to the naming convention.

[0116] S2. Wait until the local code development is completed in stages, and synchronize the code to the personal remote branch feat_ci_xxx.

[0117] S3. Real-time sense whether the code of the remote branch feat_ci_xxx has changed. If the code has changed, go to the next step; if it has not changed, continue to wait.

[0118] S4. Detect whether there is a conflict between feat_ci_xxx and target_branch. If there is a conflict, save the failure scene information, and the error code is 001; if there is no conflict, go to the next step.

[0119] S5. Based on the merged code, perform basic case detection to determine whether all cases pass. If all pass, go to the next step; if not all pass, save the failure scene information, and the error code is 002.

[0120] S6. At the same time, perform basic case detection on the feat_ci_xxx branch to determine whether all basic cases PASS. If all PASS, go to the next step; if not all PASS, save the failure scene information, and the error code is 003.

[0121] S7. If all basic case detections pass, enter the code synchronization waiting blocking queue, synchronize the current code to target_branch, clear the scene information, and the default error code is 000.

[0122] S8. Synchronize the verification result and report information of this time to the individual's Feishu.

[0123] S9. If an error occurs during the process, the relevant information will be saved for subsequent troubleshooting and handling. At the same time, the information is synchronized through Feishu to facilitate developers to timely understand the code verification situation.

[0124] Exemplarily, as Figure 7 shown, it is an interaction schematic diagram from an individual creating a remote branch to code verification and result synchronization. The following is a specific introduction:

[0125] Code push: The functional module developer (taoxf) pushes the code (code_feature) to the system, triggering the subsequent process.

[0126] Status synchronization: The information service starts to synchronize the code regression status (start regress status sync).

[0127] Smoke test trigger: After the monitoring service senses the code push, it triggers the smoke regression test (trigger sanityregress).

[0128] Concurrent scheduling: The cluster service performs process concurrent scheduling to coordinate the execution of the test.

[0129] Report generation: The database service generates a test report (make report).

[0130] Test completion notification: After the test is completed, the cluster service sends a completion message (finish) to the visualization service.

[0131] Check and repair: After receiving the notification, the functional module developer (taoxf) checks the regression test report (checkregress report). If a problem (bug) is found, it is repaired (bug fix), and then the code is pushed again (pushcode).

[0132] Full regression trigger: The full regression (full regresstrigger) can be triggered by the functional module developer (taoxf), or the full regression can be triggered periodically by the monitoring service (trigger full regress) to start a new round of complete regression test process.

[0133] Exemplarily, as Figure 8As shown in the figure, it is an iterative schematic diagram of an independent hardware sub-module. Specifically as follows: The figure shows three versions, namely the initial version 1.0.0, the iterative version 1.0.1, and the iterative version 1.0.2, which reflect the process of continuous software update and improvement. master: The main branch, usually used to store stable and releasable code versions. In the figure, the final results of each version will be merged into the master branch. release: The release branch, used for pre-release preparations, such as performing final tests and fixing minor issues. It is derived from the master branch and will eventually be merged back into the master branch. feature1, feature2, feature3: Feature branches, used for developing specific functions. Developers develop code on these branches and, after completion of development and passing the tests, merge the code into the release branch or the master branch. The process steps are as follows:

[0134] Initial version 1.0.0: In the initial stage, each feature branch (feature1, feature2, feature3) branches off from the master branch, and developers develop code on these branches respectively.

[0135] Iterative version 1.0.1: When the code development on the feature branches is completed and passes the tests, it is merged into the release branch for further testing and integration. After passing the tests, the release branch is merged into the master branch to form the iterative version 1.0.1.

[0136] Iterative version 1.0.2: Continuing the above process, after the development of new functions is completed and passes the tests, it is again integrated through the release branch and finally merged into the master branch to generate the iterative version 1.0.2.

[0137] Step S204, if the initial test result indicates that the code detection of the independent hardware sub-module is successful, then check whether there is at least one upper-layer hardware sub-system corresponding to the independent hardware sub-module.

[0138] Specifically, if the initial test result indicates that the code detection of the independent hardware sub-module is successful, the electronic device can obtain the architecture diagram of the target chip. Identify the architecture diagram of the target chip to determine the hierarchical relationship and data flow between the independent hardware sub-module and the upper-layer hardware sub-system, and then determine at least one upper-layer hardware sub-system corresponding to the independent hardware sub-module.

[0139] Step S205, if there is at least one upper-layer hardware sub-system for the independent hardware sub-module, then based on the target merge branch, perform code detection on each upper-layer hardware sub-system to generate a target detection result.

[0140] Specifically, the above step S205 may include the following steps:

[0141] Step S2051: For each upper-layer hardware subsystem, obtain other hardware submodules on which the upper-layer hardware subsystem depends, excluding independent hardware submodules.

[0142] Specifically, after determining at least one upper-layer hardware subsystem corresponding to the independent hardware submodule, for each upper-layer hardware subsystem, the electronic device identifies the architecture diagram of the target chip to determine other hardware submodules on which the upper-layer hardware subsystem depends, excluding independent hardware submodules.

[0143] Step S2052: Obtain the latest version code corresponding to the other hardware submodules.

[0144] It should be noted that the latest version code corresponding to the other hardware submodules refers to the latest code with a version number that has been successfully tested and is currently in normal use. The update code branch mentioned above refers to the latest updated code that has only been updated but not successfully tested and is not in normal use. That is to say, the latest version code is not necessarily the latest updated code, and the latest version code may be the code before the latest updated code.

[0145] Specifically, after determining other hardware submodules on which the upper-layer hardware subsystem depends, excluding independent hardware submodules, the electronic device can search for the latest version code corresponding to the other hardware submodules in the storage space.

[0146] Step S2053: Based on the target merge branch and the latest version code corresponding to the other hardware submodules, perform test case detection on the upper-layer hardware subsystem to generate a first test result.

[0147] Specifically, the electronic device can screen out test cases related to the upper-layer hardware subsystem from the project's test case library. These test cases should cover various functions and scenarios of the software subsystem, including normal use cases, boundary cases, and abnormal cases. According to the characteristics of the update code branch and the latest version code of the other hardware submodules, analyze the possible new functions, modified functions, and potential impacts, and write corresponding new test cases. For example, if the update code branch optimizes a data processing algorithm, test cases need to be written to verify the performance and correctness of the optimized algorithm. Then, organize the collected and supplemented test cases, classify and sort them according to the test type (such as functional test, performance test, compatibility test, etc.), priority, and execution order to form a complete set of test cases.

[0148] Next, the electronic device can prepare various types of test data according to the requirements of the test cases. The test data should be representative and cover different input scenarios and data ranges. For example, for an image processing software subsystem, it is necessary to prepare image data with different resolutions, different color modes, and different contents as test inputs. Deploy the test data to the test environment to ensure that the upper-layer hardware subsystem can access and use this data normally. At the same time, pay attention to the security and consistency of the data to avoid inaccurate test results due to data problems.

[0149] The electronic device can use a suitable compiler and build tools to compile the code of the upper-layer hardware subsystem. Ensure that there are no errors and warnings during the compilation process. If there are problems, they need to be investigated and resolved in a timely manner. Deploy the generated executable files, library files, etc. to the previously set up test environment to ensure that the software can be started and run normally in the test environment.

[0150] Then, the electronic device selects a suitable test framework to execute the test cases, such as JUnit (Java), PyTest (Python), etc. The test framework can help automate the execution of test cases and record the test results. Execute each test case in sequence according to the order of the sorted test case set. During the execution process, strictly follow the steps and requirements of the test cases to ensure the accuracy and repeatability of the test.

[0151] During the test execution process, the electronic device can record the execution status of each test case in detail, including information such as input data, expected output, actual output, execution time, and whether it passes. Log files or test management tools can be used to record this information.

[0152] During the test process, various abnormal situations may occur, such as program crashes, timeouts, data errors, etc. There should be corresponding exception handling mechanisms in the test framework or the code to capture these exceptions and record detailed exception information, including the exception type, occurrence location, relevant variable values, etc. When an abnormal situation occurs, analyze the cause of the exception in a timely manner. It may be a problem introduced by updating the code branch or the code of other hardware sub-modules, or it may be a defect in the test environment or the test case itself. According to the analysis results, take corresponding measures to handle it, such as fixing the code, adjusting the test environment, or modifying the test case.

[0153] In addition, the electronic device can also count the execution results of all test cases, calculate the proportion of the number of passed test cases to the total number of test cases, that is, the pass rate. The pass rate is an important indicator to measure the quality of the upper-layer hardware subsystem. For the failed test cases, carefully analyze the reasons for failure. Classify the reasons for failure, such as code logic errors, data processing errors, hardware compatibility problems, etc. According to the analysis results of the reasons for failure, locate the specific problem points to provide a basis for subsequent repair work. Use code coverage tools (such as Jacoco, Coverage.py, etc.) to check the coverage of the upper-layer hardware subsystem code by test cases, including statement coverage, branch coverage, etc. If it is found that some code areas are not covered by test cases, corresponding test cases need to be added to improve the integrity of the test. In addition to the code coverage, it is also necessary to evaluate the coverage of the upper-layer hardware subsystem functions by test cases. Ensure that all important functions have corresponding test cases for verification to avoid missing functions.

[0154] Finally, the electronic device generates a first test result based on the above statistical results of the execution of all test cases. At the beginning of the report, briefly introduce the purpose, scope, environment, etc. of the test to give readers an overall understanding of the test. List in detail the statistical data of the execution results of the test cases, including the total number of test cases, the number of passed test cases, the number of failed test cases, the pass rate, etc. These data can be presented in the form of tables or charts to make the results more intuitive. Provide a detailed description of each failed test case, including the test case number, test case name, input data, expected output, actual output, failure reason analysis, etc. At the same time, attach relevant log files and error messages so that developers can quickly locate and solve problems. Report the coverage of the test cases for the code and functions, point out the areas with insufficient coverage, and put forward corresponding improvement suggestions.

[0155] Step S2054, generate a target detection result according to the first test result.

[0156] Specifically, the above step S2054 may include the following steps:

[0157] Step a1, obtain the latest version of the code corresponding to the independent hardware sub-module.

[0158] Among them, the latest version of the code is the code with a version number that has been successfully tested before the update of the independent hardware sub-module and is currently in normal use.

[0159] Specifically, the electronic device can search for the version number that is currently in normal use in the storage space.

[0160] Step a2: Detect test cases for the upper-layer hardware subsystem based on the latest version code of the independent hardware sub-module and the latest version codes of other hardware sub-modules, and generate a second test result.

[0161] Specifically, the electronic device detects test cases for the upper-layer hardware subsystem based on the latest version code of the independent hardware sub-module and the latest version codes of other hardware sub-modules, and generates a second test result.

[0162] Among them, the process of generating the second test result can refer to the process of generating the first test result above, and will not be elaborated here.

[0163] Step a3: Generate a target detection result based on the first test result and the second test result.

[0164] Specifically, the electronic device can collect the data of the first test result and the second test result. These data may include the execution status (passed or failed) of test cases, error messages, performance metrics (such as response time, throughput, etc.), code coverage, etc. Ensure the integrity and accuracy of the data. If there is missing or incorrect data, it needs to be supplemented or corrected in time. Then, the electronic device organizes the collected data into a unified format for subsequent analysis and comparison. Tables, charts, etc. can be used to present the data to make the data more intuitive and understandable. For example, create a table listing the number, name, first test result, second test result of each test case, as well as relevant error messages and performance metrics.

[0165] The electronic device can compare the execution status of the same test cases in the first test result and the second test result one by one. If a certain test case is a super-success in the second test result but fails in the first test result, then it can be determined that this anomaly is caused by the update of the independent hardware sub-module.

[0166] In an optional implementation manner of this application, the following steps may further be included:

[0167] Step a4: For each upper-layer hardware subsystem, if the self-system code corresponding to the upper-layer hardware subsystem is updated to generate a self-system update code, obtain the latest version codes of the independent hardware sub-modules on which the upper-layer hardware subsystem depends.

[0168] Among them, the upper-layer hardware subsystem runs based on its self-system update code and the independent hardware sub-modules it depends on.

[0169] Specifically, for each upper-layer hardware subsystem, if the system code of the upper-layer hardware subsystem itself is updated to generate its own system update code, the electronic device searches the storage space for the latest version code corresponding to each independent hardware sub-module on which the upper-layer hardware subsystem depends.

[0170] Step a5: Based on the self-system update code and the latest version code corresponding to each independent hardware sub-module, perform test case detection on the upper-layer hardware subsystem.

[0171] Specifically, the electronic device performs test case detection on the upper-layer hardware subsystem based on the self-system update code and the latest version code corresponding to each independent hardware sub-module.

[0172] The process of performing test case detection on the upper-layer hardware subsystem can be referred to above and will not be elaborated here.

[0173] Step S206: If the target detection result indicates a successful detection, check whether there is at least one upper-layer hardware system corresponding to each upper-layer hardware subsystem.

[0174] Specifically, if the target detection result indicates a successful detection, the electronic device can obtain the architecture diagram of the target chip. Identify the architecture diagram of the target chip to determine the hierarchical relationship and data flow between the upper-layer hardware subsystem and the upper-layer hardware system, and then determine at least one upper-layer hardware system corresponding to the upper-layer hardware subsystem.

[0175] Step S207: If there is at least one upper-layer hardware system corresponding to each upper-layer hardware subsystem, based on the target merge branch, perform code detection on each upper-layer hardware system to generate a process detection result.

[0176] Specifically, if there is at least one upper-layer hardware system corresponding to each upper-layer hardware subsystem, the electronic device can obtain the latest version code corresponding to other upper-layer hardware sub-modules. Based on the target merge branch, determine the latest update code and the latest version code corresponding to the upper-layer hardware subsystem. Then, based on the latest version code corresponding to other upper-layer hardware sub-modules and the latest update code corresponding to the upper-layer hardware subsystem, perform test case detection on the upper-layer hardware system to generate a third test result. Based on the latest version code corresponding to other upper-layer hardware sub-modules and the latest version code corresponding to the upper-layer hardware subsystem, perform test case detection on the upper-layer hardware system to generate a fourth test result. Compare the third test result with the fourth test result to generate a process detection result.

[0177] If both the third test result and the fourth test result are test successes, determine that the process test result is a test success; if the fourth test result is a test success and the third test result is a test failure, determine that the target merge branch is incorrect.

[0178] Step S208, until based on the target merge branch, test case detection is performed on the top-level system corresponding to the target chip to generate a final detection result.

[0179] Specifically, if the process detection result is a successful test, the electronic device performs layer-by-layer testing upward based on the target merge branch until, based on the target merge branch, test case detection is performed on the top-level system corresponding to the target chip to generate a final detection result.

[0180] Exemplarily, as Figure 9 shown, it is a schematic diagram of the requirement iteration of the upper-layer hardware subsystem. As shown in the figure, code development is carried out on the feature1 branch of the upper-layer hardware subsystem. After development is completed, the relevant code may be merged into the master branch of the verification environment through a series of operations for iteration and testing. When the master branch of the verification environment passes the test, the subsequent process is triggered, and the code may be further merged into the release branch of the subsystem and finally merged into the master branch of the subsystem to complete the iteration of version 1.0.1.

[0181] Exemplarily, as Figure 10 shown, it is a schematic diagram of the process to obtain the final detection result.

[0182] S1. The integration module triggers the monitoring service to start the test process.

[0183] S2. The monitoring service triggers the functional module a and the functional module b respectively to perform a full-scale regression test.

[0184] S3. If the test of the functional module a or the functional module b fails, it is fed back to the integration module for bug fixing, and after the fixing is completed, the test is triggered again.

[0185] S4. If the tests of both the functional module a and the functional module b pass (PASS), update the latest tags or version codes of all modules (update all module latest tag or version code).

[0186] S5. After the update is completed, trigger the top-level module to perform a full-scale regression test.

[0187] S5. After the test is completed, perform report synchronization (report sync) to generate the final test result. If problems are found during the test, perform bug fixing or other processing.

[0188] The chip development method provided by the embodiments of this application detects whether there are conflicts between the updated code branch and the target remote code branch corresponding to the independent hardware sub-module. In the scenario of collaborative development of independent hardware sub-modules by multiple developers, different developers may modify different personal remote code branches simultaneously. Detecting whether there are conflicts between the updated code branch and the target remote code branch can discover potential code conflict problems in advance. For example, two developers may modify the same line of code or related code logic simultaneously. If the code is directly merged without conflict detection, it will lead to code chaos and generate errors that are difficult to debug. Through conflict detection, developers can be reminded in time to resolve conflicts, ensuring the consistency and integrity of the code. In addition, the code of independent hardware sub-modules usually has a complex logical structure, and there may be interdependencies between different personal remote code branches. Conflict detection helps to ensure the coherence between the updated code branch and the existing code logic. When the updated code branch introduces new functions or modifies existing functions, detecting conflicts can find out whether the original code logic will be damaged, avoiding function anomalies caused by code merging. If there are no conflicts between the updated code branch and the target remote code branch, the updated code branch and the target remote code branch are merged to obtain the target merged branch. This merging process greatly reduces the workload of manually merging code and improves the efficiency of code merging. Especially in large-scale chip development projects, involving a large number of personal remote code branches and frequent code updates, manual code merging is prone to errors and takes a long time. Automatic merging can avoid these problems. In addition, the merging process follows strict rules and algorithms, and can accurately integrate the updated code branch into the target remote code branch. Compared with manual merging, automatic merging can reduce human errors and ensure the accuracy of the merging result. At the same time, the system can record the detailed information of the merging process for subsequent auditing and traceability. Finally, test case detection is performed on the target merged branch to generate the initial test results. This means that the test is based on the complete merged code, which can more comprehensively verify the functions and performance of the code. Compared with testing the updated code branch and the target remote code branch separately, testing the merged code can discover new problems that may be introduced during the code merging process, such as compatibility problems and logical conflicts. By performing test case detection in time after code merging, potential problems can be discovered before the code is integrated into the main project. This can avoid introducing problematic code into subsequent development and testing phases, reducing the cost and time of problem fixing. For example, if it is found that a certain function does not work properly in the merged code, developers can locate and fix the problem in time, rather than discovering the problem during the overall system integration test. The above method defines clear code conflict detection, merging, and testing processes, making the development process more standardized and controllable. All code updates need to go through conflict detection and merging operations, and then unified test case detection is performed to ensure that the code quality meets the requirements.This standardized process helps improve the collaboration efficiency of the team and reduce problems caused by non-standardized development processes.

[0189] In addition, if the initial test results indicate that the code detection of the independent hardware sub-module is successful, then check whether there is at least one upper-layer hardware subsystem corresponding to the independent hardware sub-module; if there is at least one upper-layer hardware subsystem for the independent hardware sub-module, then for each upper-layer hardware subsystem, obtain other hardware sub-modules other than the independent hardware sub-module on which the upper-layer hardware subsystem depends. Obtain the latest version of the code corresponding to the other hardware sub-modules. Based on the target merge branch and the latest version of the code corresponding to the other hardware sub-modules, perform test case detection on the upper-layer hardware subsystem to generate a first test result, and generate a first test result. By obtaining the latest version of the code of other hardware sub-modules and conducting joint testing with the target merge branch, it is closer to the real operating environment of the system, making the first test result generated by the test case detection more accurate and reliable. Compared with only testing the update of a single hardware sub-module, more problems hidden in complex hardware interactions can be discovered, providing stronger guarantee for the quality of the system. In addition, potential incompatibility problems can be discovered in advance, avoiding software failures caused by hardware updates after system integration or going live, and improving the stability and reliability of the system. Obtain the latest version of the code corresponding to the independent hardware sub-module; based on the latest version of the code corresponding to the independent hardware sub-module and the latest version of the code corresponding to the other hardware sub-modules, perform test case detection on the upper-layer hardware subsystem to generate a second test result. Based on the first test result and the second test result, generate a target detection result. The above method can compare and analyze the first test result and the second test result, and can quantify the changes brought by the target merge branch corresponding to the independent hardware sub-module to the performance, functions, etc. of the upper-layer hardware subsystem. For example, it can determine whether the response time of the upper-layer hardware subsystem increases after the update, whether the execution efficiency of certain functions decreases, etc., which helps the development team comprehensively understand the impact of the update, so as to make more reasonable decisions, such as whether to adjust the target merge branch or adapt and optimize the upper-layer hardware subsystem. For example, if the upper-layer hardware subsystem runs normally in the second test but a specific function is abnormal in the first test, then it can be determined that the abnormality is caused by the update of the independent hardware sub-module, providing a clear direction for subsequent problem fixing and optimization. In addition, by comparing the first test result and the second test result, it can be detected whether the update introduces new security vulnerabilities or risks. During the development process, if this comparative test is not carried out, unnecessary modifications and rework may be carried out due to inaccurate assessment of the impact of the update of the independent hardware sub-module. By comparing the first test result and the second test result, the development team can more accurately judge whether the upper-layer hardware subsystem needs to be adjusted and the scope and degree of the adjustment, avoid over-modification, thereby reducing the waste of development time and resources and improving the development efficiency.

[0190] In addition, for each upper-layer hardware subsystem, if the corresponding self-system code of the upper-layer hardware subsystem is updated to generate self-system update code, the latest version of the code corresponding to each independent hardware sub-module on which the upper-layer hardware subsystem depends is obtained; based on the self-system update code and the latest version of the code corresponding to each independent hardware sub-module, test case detection is performed on the upper-layer hardware subsystem, so as to ensure the compatibility between software and hardware. When problems are found in the test, since it is clear that they occur during software self-update and the current hardware state, developers can quickly locate the root cause of the problem, whether it is an error introduced by software update or a problem with hardware interaction. For example, if data errors occur during the test, by analyzing the self-system update code and the latest version of the code corresponding to the hardware sub-module, it can be quickly determined whether it is a software algorithm error or a hardware data transmission anomaly, so as to solve the problem targeted, reduce the development cycle, and improve the development efficiency. In addition, based on the self-system update code and the latest version of the code corresponding to each hardware sub-module for detection, more comprehensive and strict quality control is carried out on the upper-layer hardware subsystem. This helps to discover problems such as logical errors and improper handling of boundary conditions in software updates, ensure that the software can work properly in the new hardware environment, improve software quality, and lay a foundation for the reliability of the entire chip system.

[0191] Finally, if the target detection result indicates that the detection is passed, it is detected whether there is at least one upper-layer hardware system corresponding to each upper-layer hardware subsystem. If there is at least one upper-layer hardware system corresponding to each upper-layer hardware subsystem, code detection is performed on each upper-layer hardware system based on the target merge branch to generate a process detection result. Until test case detection is performed on the top-level system corresponding to the target chip based on the target merge branch to generate a final detection result. It realizes the detection based on the target merge branch in sequence from the upper-layer hardware subsystem to the top-level system, and can comprehensively verify the adaptation of the target merge branch in the entire chip development system. When the final detection result shows that there are errors, since it is gradually tested from the upper-layer hardware subsystem to the top-level system, the process detection result and the final detection result can be used to accurately locate at which interaction link between which layer of hardware system and the target merge branch the error occurs. It realizes quickly determining the level where the problem lies, avoiding repeated testing of other normal levels, saving testing time and resources, and improving the development efficiency. Greatly reducing the risk in the system integration stage and improving the integration success rate and system stability.

[0192] In this embodiment, a chip development device is further provided. This device is used to implement the above-mentioned embodiments and preferred implementation manners, and those that have been described will not be elaborated again. As used hereinafter, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0193] This embodiment provides a chip development device, as Figure 11 shown, including:

[0194] A monitoring module 301, configured to monitor whether at least one personal remote code branch corresponding to an independent hardware sub-module of a target chip has been updated;

[0195] An obtaining module 302, configured to obtain an updated code branch corresponding to the personal remote code branch that has been updated if the personal remote code branch corresponding to the independent hardware sub-module has been updated;

[0196] A detection module 303, configured to perform code detection on the independent hardware sub-module based on the updated code branch to generate an initial test result.

[0197] In some alternative implementation manners, the detection module 303 is specifically configured to detect whether there is a conflict between the updated code branch and a target remote code branch corresponding to the independent hardware sub-module; the target remote code branch is used to represent the sum of the codes of each personal remote code branch in the independent hardware sub-module; if there is no conflict between the updated code branch and the target remote code branch, the updated code branch and the target remote code branch are merged to obtain a target merge branch; test case detection is performed on the target merge branch to generate an initial test result.

[0198] In some alternative implementation manners, the detection module 303 is further configured to detect whether there is at least one upper-layer hardware subsystem corresponding to the independent hardware sub-module if the initial test result indicates that the code detection of the independent hardware sub-module is successful; if there is at least one upper-layer hardware subsystem for the independent hardware sub-module, code detection is performed on each upper-layer hardware subsystem based on the target merge branch to generate a target detection result.

[0199] In some alternative implementation manners, the detection module 303 is specifically configured to, for each upper-layer hardware subsystem, obtain other hardware sub-modules other than the independent hardware sub-module on which the upper-layer hardware subsystem depends; obtain the latest version of the code corresponding to the other hardware sub-modules; perform test case detection on the upper-layer hardware subsystem based on the target merge branch and the latest version of the code corresponding to the other hardware sub-modules to generate a first test result; generate a target detection result according to the first test result.

[0200] In some alternative embodiments, the detection module 303 is specifically configured to obtain the latest version code corresponding to the independent hardware sub-module; the latest version code is the code with a version number that has been successfully tested and is currently in normal use before the update of the independent hardware sub-module; perform test case detection on the upper-layer hardware subsystem according to the latest version code corresponding to the independent hardware sub-module and the latest version codes corresponding to other hardware sub-modules, and generate a second test result; generate a target detection result according to the first test result and the second test result.

[0201] In some alternative embodiments, the detection module 303 is further configured to, for each upper-layer hardware subsystem, if the self-system code corresponding to the upper-layer hardware subsystem is updated to generate a self-system update code, obtain the latest version codes corresponding to the independent hardware sub-modules on which the upper-layer hardware subsystem depends; wherein, the upper-layer hardware subsystem runs based on the self-system update code and the independent hardware sub-modules on which it depends; perform test case detection on the upper-layer hardware subsystem based on the self-system update code and the latest version codes corresponding to the independent hardware sub-modules.

[0202] In some alternative embodiments, the detection module 303 is further configured to, if the target detection result indicates that the detection is passed, detect whether there is at least one upper-layer hardware system corresponding to each upper-layer hardware subsystem; if there is at least one upper-layer hardware system corresponding to each upper-layer hardware subsystem, perform code detection on each upper-layer hardware system based on the target merge branch to generate a process detection result; until test case detection is performed on the top-level system corresponding to the target chip based on the target merge branch to generate a final detection result.

[0203] The further function descriptions of the above-mentioned various modules and units are the same as those in the corresponding foregoing embodiments, and will not be elaborated herein.

[0204] The chip development device in this embodiment is presented in the form of functional units. Here, the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and a memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0205] The embodiment of the present invention further provides an electronic device having the above-mentioned Figure 11 shown chip development device.

[0206] Please refer to Figure 12 , Figure 12 which is a schematic structural diagram of an electronic device provided by an alternative embodiment of the present invention. As shown in Figure 12As shown, the electronic device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including a high-speed interface and a low-speed interface. Each component communicates with each other using different buses and can be installed on a common motherboard or in other ways as needed. The processor can process instructions executed within the electronic device, including instructions stored in the memory or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In some alternative embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories. Similarly, multiple electronic devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a set of blade servers, or a multi-processor system). Figure 12 Take one processor 10 as an example in

[0207] The processor 10 can be a central processing unit, a network processor, or a combination thereof. Among them, the processor 10 can further include a hardware chip. The above hardware chip can be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The above programmable logic device can be a complex programmable logic device, a field programmable gate array, a generic array logic, or any combination thereof.

[0208] Among them, the memory 20 stores instructions executable by at least one processor 10, so that at least one processor 10 executes the method shown in the above embodiments.

[0209] The memory 20 can include a program storage area and a data storage area. Among them, the program storage area can store an operating system and application programs required for at least one function; the data storage area can store data created according to the use of the electronic device and the like. In addition, the memory 20 can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some alternative embodiments, the memory 20 can optionally include a memory remotely set relative to the processor 10, and these remote memories can be connected to the electronic device through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0210] The memory 20 can include a volatile memory, such as a random access memory; the memory can also include a non-volatile memory, such as a flash memory, a hard disk, or a solid-state drive; the memory 20 can also include a combination of the above types of memories.

[0211] The electronic device further includes a communication interface 30 for the electronic device to communicate with other devices or communication networks.

[0212] Embodiments of the present invention also provide a computer-readable storage medium. The method according to the embodiments of the present invention can be implemented in hardware, firmware, or be implemented as computer code that can be recorded on a storage medium, or be implemented as computer code that is originally stored in a remote storage medium or a non-transitory machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored as such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory, a random access memory, a flash memory, a hard disk, or a solid-state drive, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by the computer, the processor, or the hardware, the method shown in the above embodiments is implemented.

[0213] A part of the present invention can be applied as a computer program product, for example, computer program instructions. When executed by a computer, through the operation of the computer, the methods and / or technical solutions according to the present invention can be called or provided. Those skilled in the art should understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executes the instructions, or the computer compiles the instructions and then executes the corresponding compiled program, or the computer reads and executes the instructions, or the computer reads and installs the instructions and then executes the corresponding installed program. Herein, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible by the computer.

[0214] Although the embodiments of the present invention are described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A chip development method, characterized in that, The method includes: For an independent hardware sub-module corresponding to a target chip, monitoring whether at least one personal remote code branch corresponding to the independent hardware sub-module is updated; If the personal remote code branch corresponding to the independent hardware sub-module is updated, obtaining the updated code branch corresponding to the updated personal remote code branch; Based on the updated code branch, performing code detection on the independent hardware sub-module to generate an initial test result.

2. The method according to claim 1, characterized in that, The performing code detection on the independent hardware sub-module based on the updated code branch to generate an initial test result includes: Detecting whether there is a conflict between the updated code branch and a target remote code branch corresponding to the independent hardware sub-module; the target remote code branch is used to represent the sum of the codes of all the personal remote code branches in the independent hardware sub-module; If there is no conflict between the updated code branch and the target remote code branch, merging the updated code branch and the target remote code branch to obtain a target merge branch; Performing test case detection on the target merge branch to generate the initial test result.

3. The method according to claim 2, characterized in that The method further includes: If the initial test result indicates that the code detection of the independent hardware sub-module is successful, detecting whether there is at least one upper-layer hardware subsystem corresponding to the independent hardware sub-module; If there is at least one upper-layer hardware subsystem for the independent hardware sub-module, based on the target merge branch, performing code detection on each of the upper-layer hardware subsystems to generate a target detection result.

4. The method according to claim 3, characterized in that, The if there is at least one upper-layer hardware subsystem for the independent hardware sub-module, based on the target merge branch, performing code detection on each of the upper-layer hardware subsystems to generate a target detection result includes: For each of the upper-layer hardware subsystems, obtaining other hardware sub-modules on which the upper-layer hardware subsystem depends except the independent hardware sub-module; Obtaining the latest version code corresponding to the other hardware sub-modules; Based on the target merge branch and the latest version code corresponding to the other hardware sub-modules, performing test case detection on the upper-layer hardware subsystem to generate a first test result; Generating the target detection result according to the first test result.

5. The method according to claim 4, wherein The generating the target detection result according to the first test result includes: Obtaining the latest version code corresponding to the independent hardware sub-module; the latest version code is the code with a version number that has been successfully tested before the update of the independent hardware sub-module and is currently in normal use; Based on the latest version code corresponding to the independent hardware sub-module and the latest version code corresponding to the other hardware sub-modules, performing test case detection on the upper-layer hardware subsystem to generate a second test result; Generating the target detection result according to the first test result and the second test result.

6. The method according to claim 4, wherein The method further includes: For each of the upper-layer hardware subsystems, if the self-system code corresponding to the upper-layer hardware subsystem is updated to generate a self-system update code, obtain the latest version codes corresponding to the independent hardware sub-modules on which the upper-layer hardware subsystem depends; wherein, the upper-layer hardware subsystem runs based on the self-system update code and the independent hardware sub-modules it depends on. Based on the self-system update code and the latest version codes corresponding to the independent hardware sub-modules, perform test case detection on the upper-layer hardware subsystem.

7. The method according to claim 3, characterized in that The method further includes: If the target detection result indicates that the detection is passed, detect whether there is at least one upper-layer hardware system corresponding to each of the upper-layer hardware subsystems. If there is at least one of the upper-layer hardware systems corresponding to each of the upper-layer hardware subsystems, based on the target merge branch, perform code detection on each of the upper-layer hardware systems to generate a process detection result. Until, based on the target merge branch, perform test case detection on the top-level system corresponding to the target chip to generate a final detection result.

8. A chip development device, characterized in that, The device includes: A monitoring module, configured to monitor whether at least one personal remote code branch corresponding to an independent hardware sub-module of a target chip is updated. An acquisition module, configured to, if the personal remote code branch corresponding to the independent hardware sub-module is updated, obtain the updated code branch corresponding to the updated personal remote code branch. A detection module, configured to perform code detection on the independent hardware sub-module based on the updated code branch to generate an initial test result.

9. An electronic device, characterized in that, Including: A memory and a processor, the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to execute the chip development method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Computer instructions are stored on the computer-readable storage medium, and the computer instructions are used to cause a computer to execute the chip development method according to any one of claims 1 to 7.

Images