Code bin multiplexing system

Abstract

The invention relates to the technical field of code warehouse management, in particular to a code warehouse multiplexing system which enables a universal module to be directly multiplexed by a plurality of projects by constructing a universal code warehouse, effectively reduces the repeated coding amount of universal logic, avoids version chaos of the universal module in different projects, and improves the efficiency of code warehouse management. The method can be applied to all projects only by updating in the universal code warehouse, the maintenance cost is effectively reduced, different projects can be flexibly adapted through combined use of the project code warehouse and the universal code warehouse, and the management efficiency of the code warehouse is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of code repository management, in particular to a code repository reuse system. BACKGROUND

[0002] At present, in the system on chip (SoC) development scene, multiple development projects usually contain the same basic logic, such as transaction driving, mathematical calculation, general test framework, etc., but each project needs to develop the code separately in the prior art, which leads to high repeated coding workload and low research and development efficiency.

[0003] Moreover, when the code repository updates and manages the common modules of multiple development projects, the module of the code repository needs to be updated project by project, and the code repository maintenance and update efficiency is poor, that is, the code repository management efficiency is poor.

[0004] Therefore, how to improve the efficiency of code repository management has become a problem to be solved. SUMMARY

[0005] In view of the above technical problems, the technical scheme adopted by the present application is as follows: A code repository reuse system, the system comprises: a general code repository, M project code repositories corresponding to M projects respectively, wherein M is a positive integer; The general code repository comprises a plurality of general modules, the general module comprises a plurality of general sequences and sequence information corresponding to each general sequence, a plurality of non-general sequences and interface information corresponding to each non-general sequence respectively, wherein the general module is a module contained in the code corresponding to the M projects respectively, the general sequence is a sequence contained in the code corresponding to the M projects respectively and the same, and the non-general sequence is a sequence not contained in at least one project or different in different projects in the corresponding general module; The project code repository comprises each non-general module corresponding to the project and sequence information corresponding to each non-general sequence.

[0006] The present application has obvious beneficial effects compared with the prior art. By the above technical scheme, the code repository reuse system provided by the present application can achieve considerable technical progress and practicality, and has wide industrial utilization value. It has at least the following beneficial effects: The present application constructs a general code repository, so that the general module can be directly reused by multiple projects, effectively reducing the repeated coding amount of the general logic, avoiding version confusion of the general module in different projects, and only needing to update in the general code repository, which can be applied to all projects, effectively reducing the maintenance cost. By combining the use of the project code repository and the general code repository, different projects can be flexibly adapted, and the efficiency of code repository management is improved. BRIEF DESCRIPTION OF DRAWINGS

[0007] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort.

[0008] Figure 1 A structural schematic diagram of a code repository multiplexing system provided by the embodiments of the present application. DETAILED DESCRIPTION

[0009] The technical solutions in the embodiments of the present application will be described clearly and completely in the following with reference to the drawings of the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, but not all the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without any creative effort are within the scope of the present application.

[0010] The embodiments provide a code repository multiplexing system, referring to Figure 1 A structural schematic diagram of a code repository multiplexing system provided by the embodiments of the present application, the system comprising: a general code repository, M project code repositories corresponding to M projects respectively, wherein M is a positive integer; The general code repository comprises a plurality of general modules, the general module comprising a plurality of general sequences and sequence information corresponding to each general sequence, a plurality of non-general sequences and interface information corresponding to each non-general sequence respectively, wherein the general module is a module contained in the code corresponding to the M projects respectively, the general sequence is a sequence contained in the code corresponding to the M projects respectively and identical, and the non-general sequence is a sequence not contained in at least one project or different in different projects in the corresponding general module; The project code repository comprises each non-general module corresponding to the project and sequence information corresponding to each non-general sequence respectively.

[0011] The general code repository can refer to a code repository storing general logic shared by all projects to support multiplexing of general logic by multiple projects.

[0012] The project code repository can refer to a code repository corresponding to a single project, which only stores non-general logic exclusive to the corresponding project.

[0013] The general module can refer to a basic unit contained in the code of all projects and consistent in function, serving as a carrier for code multiplexing.

[0014] The general sequence can refer to an executable logic segment of a general module, which is completely the same in the code of all projects and does not need to be individually modified according to the projects, such as a chip power-on initialization sequence and the like.

[0015] The non-general sequence can refer to a sequence that belongs to the general module but is not contained in all projects or has different logic in different projects.

[0016] The interface information can refer to the calling rule of the non-general sequence, can include an input parameter format, an output result type, a function name and the like, and is stored in the general code repository to ensure that the non-general sequence of the project code repository can be compatible with the general module.

[0017] The sequence information can refer to the specific execution code of the sequence, and the sequence information of the general sequence exists in the general code repository, and the sequence information of the non-general sequence exists in the project code repository.

[0018] The non-general module can refer to a unit that is exclusive to each project.

[0019] In a specific embodiment, when any project is called, the general module corresponding to the project is called from the general code repository, and the non-general module contained in the project is called from the project code repository corresponding to the project.

[0020] Among them, when a certain project is started, the code is automatically pulled on demand, the general module corresponding to the project is called from the general code repository, and the non-general module is obtained from the project code repository corresponding to the project, thereby realizing the comprehensive utilization of the general code repository and the project code repository.

[0021] Specifically, the project code repository only needs to store exclusive logic and does not need to store general logic repeatedly, thereby effectively saving the storage space of the project code repository, the general module used by all projects comes from the general code repository, thereby avoiding the existence of version differences of the general module and improving the reliability of the use of the code repository.

[0022] In a specific embodiment, the calling of the general module from the general code repository comprises: Calling the sequence information corresponding to each general sequence and the interface information respectively corresponding to each non-general sequence from the general module corresponding to the project in the general code repository; According to the interface information respectively corresponding to each non-general sequence, calling the sequence information respectively corresponding to each non-general sequence from the project code repository corresponding to the project.

[0023] Among them, when the general module is called, the execution code of the general sequence and the interface definition of the non-general sequence are taken, the specific sequence code implementing the interface is found from the project code repository according to the interface information of the non-general sequence, and then loaded and executed.

[0024] Specifically, the non-universal sequence is constrained by the interface information, ensuring the compatibility of the project custom implementation with the universal module, different projects can be implemented by different non-universal sequences, as long as the interface is consistent, the universal module does not need to be modified, and the flexibility of the code repository reuse is improved.

[0025] In a specific embodiment, the M projects each correspond to a specific sub-module included in the code, and the specific sub-module is constructed by software to form a verification data set as a universal module.

[0026] The verification data set can be a verification basic data set that can be directly reused.

[0027] Specifically, the verification data set is constructed by a software tool, which can integrate the specific sub-module, facilitate unified maintenance and update, ensure that all projects use the same verification data set, test standards are consistent, and improve verification reliability.

[0028] In a specific embodiment, the specific sub-module includes at least a transaction driver, a mathematical library, a message queue library, and a verification model.

[0029] The transaction driver can be a program responsible for converting high-level business logic into bottom-level signals recognizable by a chip in chip verification, the mathematical library can be a code set providing mathematical calculation functions required for verification, such as random number generation and matrix operation, the message queue library can be a code set managing message communication between verification components, and the verification model can be a reference model simulating the function of a chip / module.

[0030] In a specific embodiment, each non-universal module included in the project code repository is divided into an SOC module and an IP module, wherein the SOC module includes a plurality of SOC sequences, and the IP module includes a plurality of IP sequences.

[0031] The SOC module can be a system-level functional module, and the IP module can be an IP core functional module, and the SOC is composed of multiple IPs.

[0032] The SOC module includes a plurality of SOC sequences, and each SOC sequence is used to implement a system-level test scenario or an initialization process.

[0033] The IP module includes a plurality of IP sequences, and each IP sequence is used to implement a test scenario or an initialization process of a corresponding IP core.

[0034] In a specific embodiment, when the SOC module is called, the same SOC sequence as the IP sequence in the SOC module calls the corresponding IP sequence.

[0035] When the IP core is integrated into the SOC, that is, the reusable relationship between the SOC sequence in the SOC module and the IP sequence in the IP module is determined, when the project code warehouse is called, if the SOC sequence in the SOC module is completely the same as the existing IP sequence in the IP module, the SOC module will not be repeatedly implemented, but directly call the corresponding sequence of the IP module.

[0036] Specifically, the embodiment avoids repeatedly writing the logic that has been implemented by the IP layer in the SOC layer, reduces code redundancy, further improves the code reuse rate through the vertical calling of the project code warehouse, and further improves the code warehouse management efficiency.

[0037] In a specific embodiment, the general module at least includes a SoC test base class, a SoC root environment and a verification data set.

[0038] The SoC test base class can be a basic parent class of all SOC project test cases, encapsulates general test logic, so that the project test case can be directly inherited and extended, and repeated writing is avoided.

[0039] The SoC root environment can be a top container of the SOC verification environment, responsible for integrating the SOC module, the IP module and the general module, and providing a complete running environment for testing.

[0040] In the embodiment, by constructing the general code warehouse, the general module can be directly reused by multiple projects, effectively reducing the amount of repeated coding of general logic, and avoiding version confusion of the general module in different projects. Only the general code warehouse needs to be updated, which can be applied to all projects, effectively reducing the maintenance cost. By using the project code warehouse and the general code warehouse together, different projects can be flexibly adapted, and the efficiency of code warehouse management can be improved.

[0041] Although some specific embodiments of the present application have been described in detail by examples, those skilled in the art should understand that the above examples are only for illustration, not for limiting the scope of the present application. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the present application. The scope of the present application is defined by the appended claims.

Claims

1. A code repository reuse system, characterized in that, The system includes: a general code repository and M project code repositories corresponding to each project, where M is a positive integer; The general code repository includes several general modules. Each general module includes several general sequences and sequence information corresponding to each general sequence, several non-general sequences and interface information corresponding to each non-general sequence. A general module is a module that is included in the code of each of the M projects. A general sequence is a sequence that is included in the code of each of the M projects in the corresponding general module and is the same. A non-general sequence is a sequence that is not included in at least one project in the corresponding general module or exists in different projects. The project code repository includes sequence information corresponding to each non-general module and each non-general sequence of the project.

2. The code repository reuse system according to claim 1, characterized in that, When calling any project, the general module corresponding to the project is called from the general code repository, and the non-general module contained in the project is called from the project code repository corresponding to the project.

3. The code repository reuse system according to claim 2, characterized in that, The step of calling the general module corresponding to the project from the general code repository includes: From the general module corresponding to the project in the general code repository, call the sequence information corresponding to each general sequence and the interface information corresponding to each non-general sequence; Based on the interface information corresponding to each non-generic sequence, the sequence information corresponding to each non-generic sequence is called from the project code repository corresponding to this project.

4. The code repository reuse system according to claim 1, characterized in that, Each of the M projects contains a specific sub-module in its code, which is then used by software to construct a validation dataset as a general module.

5. The code repository reuse system according to claim 4, characterized in that, The specific submodule includes at least a transaction driver, a math library, a message queue library, and a verification model.

6. The code repository reuse system according to claim 1, characterized in that, The project code repository contains various non-general modules, which are divided into SOC modules and IP modules. The SOC module includes several SOC sequences, and the IP module includes several IP sequences.

7. The code repository reuse system according to claim 6, characterized in that, When the SOC module is invoked, the SOC sequence in the SOC module that is the same as the IP sequence invokes the corresponding IP sequence.

8. The code repository reuse system according to claim 7, characterized in that, The general module includes at least a SoC test base class, a SoC root environment, and a verification dataset.

Images