A hardware unit warehousing method, device, electronic equipment and storage medium

Abstract

The application discloses a hardware unit warehousing method and device, electronic equipment and storage medium, and relates to the technical field of computers.The method comprises the following steps: scanning and processing project files of a hardware design project, determining hardware units contained in the hardware design project and hardware unit information of the hardware units; determining the design verification maturity of the hardware units according to the hardware unit information, and setting a warehousing form of the hardware units by using the design verification maturity and the hardware unit information; querying the warehousing form, and judging whether the hardware units have the design verification maturity meeting preset warehousing conditions; if the hardware units have the design verification maturity meeting the preset warehousing conditions, verifying hardware unit files of the hardware units, and judging whether the hardware units pass the verification; if the hardware units pass the verification, adding the hardware unit files and verification information of the hardware units to a hardware unit management library, and updating the warehousing identifier of the hardware units to the warehousing form; and the automatic warehousing of the hardware units can be realized.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for storing hardware units. Background Technology

[0002] To ensure effective management of hardware units (IP cores), timely inventory management of hardware units is of great importance.

[0003] In related technologies, hardware units rely on manual warehousing, which leads to poor reliability and low standardization in hardware unit warehousing. Summary of the Invention

[0004] The purpose of this invention is to provide a method, apparatus, electronic device, and storage medium for warehousing hardware units, which can realize automated warehousing of hardware units, avoid manual warehousing, and thus improve warehousing efficiency.

[0005] To address the aforementioned technical problems, this invention provides a method for storing hardware units in a database, comprising: The project files of the hardware design project are scanned to determine the hardware units contained in the hardware design project and their information. The design verification maturity of the hardware unit is determined based on the hardware unit information, and the hardware unit entry form is set up using the design verification maturity and hardware unit information. Query the inbound form to determine whether there are hardware units whose design verification maturity meets the preset inbound conditions; If there is a hardware unit whose design verification maturity meets the preset inclusion conditions, then the hardware unit file of the hardware unit is verified, and it is determined whether the hardware unit passes the verification. If the hardware unit passes verification, the hardware unit file and verification information of the hardware unit are added to the hardware unit management library, and the entry identifier of the hardware unit is updated to the entry form.

[0006] Optionally, the project files of the hardware design project are scanned to determine the hardware units included in the hardware design project and their information, including: The project files of the hardware design project are scanned to determine the hardware unit files and their project paths, and the information of the person in charge of the hardware unit is obtained. Determine the source type of the hardware unit based on the first keyword in the project path; The design verification version information of the hardware unit is determined based on the second keyword in the hardware unit file and / or the third keyword in the hardware unit file name. Based on the hardware unit file, determine the types of files already included in the hardware unit; Determine the unit type of the hardware unit based on the file extension of the hardware unit file; The hardware unit files are verified to obtain the verification coverage information of the hardware units.

[0007] Optionally, the design verification maturity of the hardware unit is determined based on the hardware unit information, including: Based on preset conditions, determine the design verification maturity corresponding to the design verification version information, included file types, and verification coverage information.

[0008] Optionally, it also includes: Periodically scan the project files of the hardware design project and determine whether the hardware unit information of the hardware unit has been updated. If hardware unit information is updated, the updated hardware unit information is used to update the hardware unit entry form.

[0009] Optionally, the hardware unit file of the hardware unit is verified, including: Static and dynamic verification processes are performed on the hardware unit files to obtain the functional coverage log and code coverage log of the hardware unit. Based on the functional coverage log and code coverage log, determine whether the hardware unit has passed verification.

[0010] Optionally, after adding the hardware unit file and verification information of the hardware unit to the hardware unit management library, the following steps are also included: Based on the hardware unit's inventory form, determine whether the design verification maturity of the hardware unit has declined; If the design verification maturity of a hardware unit declines, the hardware unit file and verification information in the hardware unit management library will be backed up to the hardware unit backup library. Delete the hardware unit file and verification information in the hardware unit management library.

[0011] Optionally, it also includes: If it is detected that a hardware unit imports another target hardware design project from the hardware unit management library, the mapping relationship between the hardware unit and the source hardware design project and the target hardware design project of the hardware unit is recorded in the hardware unit management library; If it is determined that a hardware unit has been updated in the target hardware design project, and the design verification maturity of the hardware unit meets the preset inclusion conditions and the hardware unit has passed verification, then the hardware unit file and verification information of the hardware unit in the target hardware design project will be added back to the hardware unit management library.

[0012] The present invention also provides a hardware unit storage device, comprising: The scanning module is used to scan the project files of the hardware design project to determine the hardware units contained in the hardware design project and their information. The inbound form setting module is used to determine the design verification maturity of hardware units based on hardware unit information, and to set the inbound form of hardware units using the design verification maturity and hardware unit information. The inbound judgment module is used to query the inbound form and determine whether there are hardware units whose design verification maturity meets the preset inbound conditions. The inbound verification module is used to verify the hardware unit file of a hardware unit if the design verification maturity meets the preset inbound conditions, and to determine whether the hardware unit passes the verification. The entry module is used to add the hardware unit file and verification information of the hardware unit to the hardware unit management library if the hardware unit passes the verification, and update the entry identifier of the hardware unit to the entry form.

[0013] The present invention also provides an electronic device, comprising: Memory, used to store computer programs; The processor is used to implement the above-mentioned hardware unit loading method when executing computer programs.

[0014] The present invention also provides a non-volatile computer-readable storage medium storing computer-executable instructions, which, when loaded and executed by a processor, implement the above-described hardware unit loading method.

[0015] This invention provides a method for adding hardware units to a database, comprising: scanning project files of a hardware design project to determine the hardware units included in the hardware design project and their information; determining the design verification maturity of the hardware units based on the hardware unit information, and setting up a database entry form for the hardware units using the design verification maturity and the hardware unit information; querying the database entry form to determine whether there are hardware units whose design verification maturity meets preset database entry conditions; if there are hardware units whose design verification maturity meets preset database entry conditions, verifying the hardware unit files of the hardware units and determining whether the hardware units pass the verification; if the hardware units pass the verification, adding the hardware unit files and verification information of the hardware units to a hardware unit management database, and updating the database entry identifier of the hardware units to the database entry form.

[0016] The beneficial effects of this invention are as follows: This invention can automatically scan and process project files of hardware design projects to determine the hardware units included in the hardware design project and their information. Subsequently, the design verification maturity of the hardware units can be determined based on the hardware unit information, and an entry form for the hardware units can be set up using the design verification maturity and hardware unit information. This allows for determining whether the hardware units meet the entry requirements based on the design verification maturity and standardizing the entry information using the entry form. Then, the entry form can be queried to determine if there are hardware units whose design verification maturity meets the preset entry conditions. If there are hardware units whose design verification maturity meets the preset entry conditions, the hardware unit files of the hardware units are verified, and it is determined whether the hardware unit passes the verification. If the hardware unit passes the verification, the hardware unit files and verification information are added to the hardware unit management library, and the entry identifier of the hardware unit is updated to the entry form. In this way, this invention can achieve automated entry of hardware units, avoiding manual entry and thus improving the entry efficiency.

[0017] The present invention also provides a hardware unit storage device, an electronic device, and a storage medium, which have the above-mentioned beneficial effects. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a method for storing hardware units in a database, as provided in an embodiment of the present invention; Figure 2 A flowchart illustrating the complete IP database management implementation process provided in this embodiment of the invention; Figure 3 A flowchart of the hardware unit database structured form capture process provided in this embodiment of the invention; Figure 4 An automated calibration flowchart for hardware unit maturity is provided for embodiments of the present invention; Figure 5 A comparative schematic diagram of the automated inspection integration process provided in the embodiments of the present invention; Figure 6 A management flowchart for IP status rollback is provided in this embodiment of the invention; Figure 7 A flowchart for managing multiple project branches is provided as an embodiment of the present invention; Figure 8Another flowchart for managing multiple project branches provided in this embodiment of the invention; Figure 9 A structural block diagram of a hardware unit warehousing device provided in an embodiment of the present invention; Figure 10 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] To ensure effective management of hardware units (IP cores), timely inventory management of hardware units is of great importance.

[0022] In related technologies, hardware units rely on manual input into the database; however, this has the following drawbacks: 1. Traditional processes rely on manual collection, entry, and inspection of IP data, which are cumbersome and prone to data omissions or errors due to negligence, increasing management costs and risks. 2. The hardware units used in different projects are managed using independent branches, lacking unified version control, which leads to version conflicts, fragmented management, and difficulties in tracing. 3. When the same hardware unit is reused in multiple projects, it is difficult to ensure the consistency of hardware unit versions in each project manually, which can easily lead to version confusion or functional mismatch. 4. Traditional methods require manual verification of hardware unit design rules, functional coverage, and code coverage using version numbers, which makes it difficult to guarantee the quality and reliability of the hardware units entering the warehouse. In view of this, in order to achieve automatic warehousing of hardware units and avoid the defects of poor reliability and low standardization of manual warehousing, the present invention can provide a hardware unit warehousing method, which can realize the automatic warehousing of hardware units, avoid manual warehousing, and thus improve the warehousing efficiency.

[0023] Please refer to Figure 1 , Figure 1 A flowchart of a hardware unit storage method provided in an embodiment of the present invention, the method may include: S11. Scan the project files of the hardware design project to determine the hardware units included in the hardware design project and their information.

[0024] In this embodiment, a hardware design may contain several hardware units. For example, a System-on-Chip (SoC) often needs to integrate hundreds of hardware units such as processor cores, memory, interface protocols, and simulation modules. Therefore, the project files of a hardware design project may contain hardware unit files for each hardware unit, such as design code files and design documentation files.

[0025] Project files for hardware design projects can be stored uniformly in the storage system. Furthermore, for ease of management, a development library can be set up for each hardware design project, and this library can be used to store hardware unit files that are currently under development within the project.

[0026] To promptly identify and manage fully functional and reliable hardware units, this embodiment first scans the project files of the hardware design project to determine the hardware units included in the project and their information. The hardware unit information may include the hardware unit name, unit type, source type, associated project name, responsible person information, design verification version information, verification coverage information, and the file type corresponding to the hardware unit file. This information can be used for both recording inbound data and determining whether the hardware unit is functionally complete and meets stability standards, thereby determining whether the hardware unit meets the inbound requirements.

[0027] The following describes a method for obtaining hardware unit information. In one implementation, scanning the project files of a hardware design project to determine the hardware units included in the hardware design project and their information may include: S111. Scan the project files of the hardware design project to determine the hardware unit files and their project paths, and obtain the information of the person in charge of the hardware unit.

[0028] In this step, the hardware unit file and its project path can be determined by scanning the project files of the hardware design project. Additionally, information about the person responsible for submitting the hardware unit file to the system can be obtained.

[0029] S112. Determine the source type of the hardware unit based on the first keyword in the project path.

[0030] In this step, the source type indicates whether the hardware unit is a self-developed hardware unit or a hardware unit imported from a third party. Since the source of the hardware unit can be indicated in the project path, such as internal.work indicating a self-developed hardware unit and external.work indicating a third-party hardware unit, the source type of the hardware unit can be determined based on the first keyword in the project path.

[0031] S113. Determine the design verification version information of the hardware unit based on the second keyword in the hardware unit file and / or the third keyword in the hardware unit file name.

[0032] In this step, the design verification version information includes the design version and verification version of the hardware unit. This information can be extracted from the hardware unit file or from the filename of the hardware unit file. For example, for filenames such as "XX_v0.3.doc", "xx.sv V0.3", "XXX_v0.3_checklist.excel", and "XXX_v0.5_checklist.excel", the corresponding version information can be determined by "v0.3" and "v0.5".

[0033] S114. Determine the included file type of the hardware unit based on the hardware unit file.

[0034] In this step, the types of files included in the hardware unit files may vary depending on the development progress of the hardware unit. For example, the early stage may include design code files, design documents, verification plans, and verification item review feedback forms; the mid-stage may include design code files, design documents, verification inspection reports, mid-stage inspection feedback forms, and mid-stage verification feedback forms; and the later stage may include design code files, design documents, SDC constraint files, late-stage inspection feedback forms, and late-stage verification feedback forms. Therefore, the development progress of the hardware unit can be determined based on the types of files included.

[0035] S115. Determine the unit type of the hardware unit based on the file extension of the hardware unit file.

[0036] In this step, hardware units can include three types: soft cores, hybrid cores, and hard cores. Soft cores are provided in the form of hardware description languages ​​(such as Verilog or VHDL), and they are parameterized, synthesizable code. Hybrid cores include some pre-placed and routed logic gates and configurable logic sections, which can be further optimized using synthesis tools. Hard cores are fully synthesized and placed-routed IP, pre-designed and optimized for a specific process node. The development schedule of the hardware unit can also be determined based on the unit type.

[0037] This step determines the unit type of the hardware unit based on its file extension. For example, the extension for a soft core is ".sv", the extension for a hybrid core is ".sv" + ".db", and the extension for a hard core is ".lib".

[0038] S116. Verify the hardware unit file to obtain the verification coverage information of the hardware unit.

[0039] In this step, the hardware unit files can also be verified to obtain verification coverage information for the hardware units, such as functional coverage and code coverage, which also helps to determine the maturity of the hardware units.

[0040] S12. Determine the design verification maturity of the hardware unit based on the hardware unit information, and set up the hardware unit entry form using the design verification maturity and hardware unit information.

[0041] In this step, the design verification maturity of the hardware unit is first determined based on the hardware unit information. Design verification maturity indicates the functional completeness and reliability of the hardware unit. This invention provides at least three design verification maturity nodes: IP0.3, IP0.5, and IP0.8, corresponding to basic functional verification (30% coverage), core performance compliance (80% coverage), and full-scenario acceptance (100% coverage + constraint completeness), respectively, achieving full-cycle quality control from R&D to warehousing. Furthermore, corresponding preset conditions are set for each design verification maturity node to match with the hardware unit information to determine the design verification maturity of the corresponding hardware unit, as shown in the table below: Table 1 Maturity Rule Base

[0042] The maturity rules mentioned above can be configured in the Yaml configuration file to meet monitoring needs. This rule base supports user customization (such as adding an IP0.9 level), and also supports the integration of multiple indicators such as code integrity (e.g., IP0.3 requires code + documentation + feedback form), verification coverage (30% / 80% / 100%), and physical constraints (SDC file), which can ensure that the judgment results are scientific and rigorous.

[0043] In this way, by using matching rules, it is possible to clearly determine whether the hardware unit is mature and whether it meets the requirements for warehousing.

[0044] Based on this, determining the design verification maturity of a hardware unit according to its information can include: S121. Based on preset conditions, determine the design verification maturity corresponding to the design verification version information, included file types, and verification coverage information.

[0045] Furthermore, after determining the design verification maturity level, this embodiment can use the design verification maturity level and hardware unit information to set up an inbound form for the hardware units. This inbound form contains the necessary information required for the hardware units to be inbound. This inbound form will be continuously associated with the hardware units for inbound management. For example, a possible inbound form is shown in the table below: Table 2 Example of a structured form for IP address entry

[0046] S13. Query the inbound form to determine whether there are hardware units whose design verification maturity meets the preset inbound conditions.

[0047] In this embodiment, after setting up the inbound form, the inbound form can be queried to determine whether there are hardware units whose design verification maturity meets the preset inbound conditions. For example, when it is determined that the design verification maturity reaches IP0.8, it can be determined that the hardware unit meets the preset inbound conditions, and the inbound process can be executed.

[0048] S14. If there is a hardware unit whose design verification maturity meets the preset entry conditions, then verify the hardware unit file of the hardware unit and determine whether the hardware unit passes the verification.

[0049] In this embodiment, since the focus is on storing mature hardware units, in order to ensure reliability, an automatic verification can be performed on the hardware units before storage to verify their maturity.

[0050] Specifically, static and dynamic verification processes can be performed on the hardware unit files to obtain functional coverage logs and code coverage logs. Subsequently, based on these logs, it can be determined whether the hardware unit has passed verification.

[0051] Based on this, verifying the hardware unit file of the hardware unit can include: S141. Perform static and dynamic verification processing on the hardware unit files to obtain the functional coverage log and code coverage log of the hardware unit.

[0052] In this step, the VC_spyglass tool can be used for static verification of the hardware unit files, and test cases and the VSC / UVM toolchain can be used for dynamic verification of the hardware unit files. The specific verification process can be as follows: 1) Code environment update: Connect to the version control system and pull the latest code from the project branch containing the corresponding hardware unit; 2) Tool adaptation: Encapsulates the tool command calls for VC Spyglass, VCS, and UVM; 3) Tool Environment Operation: VC Spyglass is used to check design rules such as CDC, Lint, and timing constraints (SDC) to intercept cross-clock domain risks and code standardization defects; based on the VCS simulation engine, UVM test cases are loaded to complete stress tests on functional coverage and interface flip rate to ensure the robustness of the IP under extreme scenarios.

[0053] S142. Determine whether the hardware unit has passed verification based on the functional coverage log and code coverage log.

[0054] This step generates compilation log files for VC Spyglass, as well as VCS feature coverage and code coverage log files. It also sets report file filtering rules, providing options to filter log files and output a comprehensive report. These rules can be modified and added by the designer. The following is an example of file filtering rule settings: Table 3 VC Spyglass Inspection Rules

[0055] Table 4 VCS Inspection Rules

[0056] Furthermore, based on the functional coverage log and code coverage log, it can be determined whether the hardware unit has passed verification.

[0057] S15. If the hardware unit passes the verification, add the hardware unit file and verification information of the hardware unit to the hardware unit management library, and update the entry identifier of the hardware unit to the entry form.

[0058] In this embodiment, if the hardware unit passes verification, its hardware unit files and verification information are added to the hardware unit management library. For example, based on the hardware unit keywords in the development library's design and verification paths, the system searches for related hardware unit files, code, verification environment, and verification test cases. Corresponding folders are then created to store the relevant content for each hardware unit file based on its files, code, verification environment, and verification test cases.

[0059] Additionally, the entry identifier for hardware units can be updated in the entry form. For example, a unique identifier can be generated based on the associated items of the hardware unit.

[0060] Based on the above embodiments, this invention can automatically scan project files of hardware design projects to determine the hardware units included in the hardware design project and their information. Subsequently, the design verification maturity of the hardware units can be determined based on the hardware unit information, and an entry form for the hardware units can be set up using the design verification maturity and hardware unit information. This allows for determining whether the hardware units meet the entry requirements based on the design verification maturity and standardizing the entry information using the entry form. Then, the entry form can be queried to determine if there are hardware units whose design verification maturity meets the preset entry conditions. If there are hardware units whose design verification maturity meets the preset entry conditions, the hardware unit files of the hardware units are verified, and it is determined whether the hardware unit passes the verification. If the hardware unit passes the verification, the hardware unit files and verification information are added to the hardware unit management library, and the entry identifier of the hardware unit is updated to the entry form. In this way, this invention can achieve automated entry of hardware units, avoiding manual entry and thus improving the entry efficiency.

[0061] Based on the above embodiments, in order to improve the reliability of hardware entry into the warehouse and avoid missed detection, this embodiment can periodically scan the project files of the hardware design project, and actively update the corresponding entry form when it is determined that the hardware unit information has been updated, so as to promptly discover hardware units that meet the entry conditions.

[0062] Based on this, the method may also include: S21. Periodically scan the project files of the hardware design project and determine whether the hardware unit information of the hardware unit has been updated.

[0063] It should be noted that this embodiment does not limit the specific duration of the cycle; for example, it can be three months.

[0064] S22. If the hardware unit information is updated, the updated hardware unit information is used to update the hardware unit entry form.

[0065] Based on the above embodiments, in this embodiment, since hardware units may be rolled back after being stored in the database, in order to achieve effective backup, when it is determined that a hardware unit has been rolled back or the design verification maturity has decreased to the point of not meeting the requirements, the files of the hardware units that have been stored in the database can be backed up.

[0066] Based on this, after adding the hardware unit file and verification information of the hardware unit to the hardware unit management library, it may also include: S31. Based on the hardware unit's inventory entry form, determine whether the design verification maturity of the hardware unit has decreased. S32. If the design verification maturity of the hardware unit decreases, back up the hardware unit file and verification information in the hardware unit management library to the hardware unit backup library. S33. Delete the hardware unit file and verification information in the hardware unit management library.

[0067] As can be seen, by backing up the hardware unit files and verification information, this embodiment retains the mature hardware unit design on the one hand, and facilitates the use of the hardware unit design in other projects in the future on the other hand.

[0068] Furthermore, after a hardware unit is introduced into the library by other projects, if the hardware unit does not add any new functions, only the corresponding mapping information can be recorded in the management library to save resources; if the hardware unit adds new functions, and the design verification maturity of the hardware unit meets the preset library entry conditions and the hardware unit passes verification, then the hardware unit file and verification information of the hardware unit in the target hardware design project will be added back to the hardware unit management library.

[0069] Based on this, the method may also include: S41. If it is detected that a hardware unit imports another target hardware design project from the hardware unit management library, then the mapping relationship between the hardware unit and the source hardware design project and the target hardware design project of the hardware unit is recorded in the hardware unit management library. S42. If it is determined that the hardware unit has been updated in the target hardware design project, and the design verification maturity of the hardware unit meets the preset entry conditions and the hardware unit has passed verification, then the hardware unit file and verification information of the hardware unit in the target hardware design project will be added back to the hardware unit management library.

[0070] The following section describes the hardware unit warehousing method based on specific diagrams. This invention employs a SoC hardware unit warehousing method based on multi-dimensional structured modeling and dynamic management, completing the management of IP core (hardware unit) warehousing in three stages. Starting with project nodes, the hardware unit warehousing node requirements are abstracted into configurable structured warehousing forms. These structured forms act as events, triggering quality verification for design rule checks and functional verification checks. After completing the hardware unit integrity check, the hardware unit warehousing data is integrated and the hardware units are dynamically managed. This improves the efficiency and reduces the error-prone nature of manual hardware unit warehousing operations. Furthermore, dynamic hardware unit warehousing management provides IP reuse and version tracking across different projects. Please refer to [link / reference]. Figure 2 , Figure 2 This is a flowchart illustrating the complete IP database management process provided in this embodiment of the invention. The process includes three parts: constructing a structured IP database form, automated inspection and integration, and dynamic management of hardware units.

[0071] I. Construct a structured form for IP address entry: Based on the IP entry management process and entry requirements, the IP entry requirements are abstracted into a structured IP entry form from five dimensions: IP maturity level management, multi-dimensional definition of IP categories, IP source, entry status control, and quality verification status. Please refer to... Figure 3 , Figure 3 A flowchart illustrating the structured form retrieval process for hardware unit data entry in an embodiment of the present invention. The process includes: 1. Periodic Inspection: The backend sets periodic inspection time windows (e.g., 3 months), and uses automated inspection to scan the IP status in the project to ensure the real-time and complete statistics of the number of IPs, avoiding the risk of manual omissions; 2. Maturity assessment: Please refer to... Figure 4 , Figure 4 The flowchart provided in this embodiment of the invention illustrates the automated calibration process for hardware unit maturity, enabling an automated calibration method for IP maturity. a) User IP Source List: Obtain a list of all IPs for the project through periodic inspections, such as... Figure 4 Step 1; b) Key IP Information Extraction: Extract key IP information based on the IP's path and associated submitter, such as... Figure 4 Step 2; c) Maturity Rule Establishment: Maturity rule monitoring can be performed by inputting the maturity rule base settings based on Table 1 below into a Yaml file. This rule base allows users to customize rule extensibility (e.g., adding IP0.9 level), and supports the integration of multiple indicators such as code integrity (e.g., IP0.3 requires code + documentation + feedback form), validation coverage (30% / 80% / 100%), and physical constraints (SDC file) to ensure scientific and rigorous judgment results. Table 1 below shows an example of a maturity rule base. Figure 4 Step 3; d) Maturity Detection: Based on the basic information of the captured IPs, determine the content to be crawled. This includes determining whether the crawled content contains information such as IP rule base setting requirements. For example... Figure 4 In step ④, the Maturity content of the captured IP0 is: "XX_v0.3.doc, xx.sv / / V0.3,XXX_v0.3_checklist.excel,XXX_v0.5_checklist.excel", as shown in step ④; e) Maturity assessment: Based on the above, the IP maturity level is determined to be IP0.3, not IP0.5, as shown in step ⑤ of the figure; f) Output IP maturity: IP maturity not reaching IP0.5, reaching IP0.3 → IP0.3, as shown in step ⑥; Path semantic analysis: Intelligently distinguishes self-developed IPs from third-party IPs by project path keywords (such as internal.work vs external.work), and automatically binds the responsible person with the submitter information to build a responsibility chain traceability system. It can also dynamically manage the entry of IPs into the database and query whether the IP has been entered into the database, and identify the unique entry mark. File characteristic identification: Automatically determine IP category based on RTL file extensions (.sv / .db / .lib). Soft core (.sv only): Parameterized code that supports flexible refactoring; Hybrid core (.sv+.db): Combining pre-layout with configurable logic; Hardcore (.lib only): A process-customized physical core that ensures timing convergence.

[0072] Based on the above three-stage process, a structured form for IP entry into the database can be created for all IPs in the project.

[0073] II. Integration of Automated Inspection

[0074] Automated inspection integration, driven by an intelligent engine and through end-to-end automated verification, constructs a "digital defense line" for IP entry quality, upgrading the traditional discrete verification process into a closed-loop, adaptive, and scalable intelligent quality inspection system. Based on parsing the structured IP entry form content, it queries the IP maturity threshold of the structured form to trigger static and dynamic verification of the IP. For easier understanding, please refer to... Figure 5 , Figure 5 This diagram illustrates a comparison of the automated inspection integration process provided in an embodiment of the present invention. The diagram shows a comparison of the implementation steps of traditional inspection and the automated inspection integration method of the present invention.

[0075] 1. Input Form Configuration: Based on the IP form construction and parsing described above, automatically enter the form information status of IPs in the project to complete the automated entry of the structured IP database form; 2. Polling Query: Query the maturity level of the form based on settings and parse the IP maturity level. When the IP maturity level reaches the preset threshold (IP 0.8), parse the IP table parameters and generate a task. If the threshold is not reached, table parsing and automated integration checks are not enabled. 3. Engine Startup: Receives the status of all IPs that have reached IP0.8 and caches all pending tasks. For IPs that have reached IP0.8, multi-process processing is performed. Static and dynamic verification engines are started for each IP. These engines address the heterogeneity and task dependencies between different tools. Engine startup includes the following specific tasks: 1) Code environment update: Connect to the version control system and pull the latest code from the project branch corresponding to the IP address; 2) Tool adaptation: Package tool command calls for VC Spyglass, VCS, and UVM; 3) Tool Environment Operation: VC Spyglass is used to check design rules such as CDC, Lint, and timing constraints (SDC) to intercept cross-clock domain risks and code standardization defects; based on the VCS simulation engine, UVM test cases are loaded to complete stress tests on functional coverage and interface flip rate to ensure the robustness of the IP under extreme scenarios.

[0076] 4. Report Generation: Generates compilation log files for VC Spyglass and VCS feature coverage and code coverage log files; 5. Report Filtering: Configure report file filtering rules, providing settings to filter log files and output a comprehensive report. These rules can be modified and added by designers. 6. Dynamic Status Update: The verification results (PASS / ERROR) are written back to the IP structured form in real time to form a quality profile; 7. Notification Mechanism: Use notification mechanisms to push notifications to the person in charge of the bound IP address, and build a closed-loop response chain for issues.

[0077] 8. IP Data Integration: IPs with an IP maturity level of 0.8 and an automated check result of PASS are captured and organized according to the IP structured form content and stored in the dynamic IP management database.

[0078] III. Dynamic IP Management: Dynamic IP management involves managing the IPs that have completed automated checks and integration. Dynamic IP management is divided into two main categories: initial IP entry management and entry management of different project branches of IPs.

[0079] The initial IP storage management and the management of different project branches have the following three main practical application scenarios in the project: 1. After the IP reaches the 0.8 status and is entered into the database, the IP function needs to be added; 2. After the IP reaches the 0.8 state and is entered into the database, the IP state needs to be rolled back to allow for design function debug fixes. 3. Once an IP reaches a 0.8 status and is entered into the database, it does not need to be entered into the database again if it is not used in the project. Due to the aforementioned practical issues, the IP management library is configured as three control and management libraries: an IP development library, an IP management library, and an IP backup mechanism library. The main functions of these three libraries are: 1. IP Development Library: For actual project development, it supports designers in iterating IP code design, building verification environment for testing, and carrying out early research and development and debugging; 2. IP Management Library: Contains verified IPs with an IP maturity level of 0.8; 3. IP Backup Mechanism Library: Stores historical versions and obsolete IPs, supports version rollback and cross-project reuse, avoids redundant development and releases management library resources.

[0080] The following is an analysis of the workflow for three IP address entry management scenarios: 1. Management process for IP status rollback after initial entry into the database when IP0 reaches IP0.8: Please refer to Figure 6 , Figure 6 This is a management flowchart for IP status rollback provided in an embodiment of the present invention.

[0081] 1) After the maturity level of IP0 in the project development library has reached the IP0.8 requirement, find the relevant IP files, code, verification environment, and verification testcase related content according to the IP keywords under the path corresponding to the design and verification of the development library. Create corresponding folders for the IP files according to the files, code, verification environment, and verification testcase to store the relevant content. 2) Upload the IP0 package file to the IP management database and generate a unique identifier (A_project_IP0_0.8) based on the associated items in the IP structured form. 3) When the IP0 structured form detects and compares the IP maturity of the project's IP and finds that it does not match the IP maturity flag in the IP management database, for example, if the IP0 maturity reverts to the IP0.5 state, then A_project_IP0_0.8 in the IP management database will be uploaded to the IP backup mechanism database, and the uploaded content of A_project_IP0_0.8 in the IP management database will be deleted at the same time. 4) If IP0 is no longer used in project A after being added to the IP management database, the IP handling process is the same as steps 1.2.3 above, and will not be repeated here. 2. IP0 functionality is not added / modified during the management process across multiple project branches: Please refer to Figure 7 , Figure 7 This invention provides a flowchart for managing multiple project branches.

[0082] 1) If IP0 is added to the database under project A and then used in project B, and the IP maturity level is not updated during the use process (no new or modified IP functions are added), then the IP will be uploaded to the database management system in project B. 2) In the uploaded IP management database, only update the entry representation of IP0 (A_B_project_IP0_0.8), recording that IP0 is used in both projects A and B; 3. IP0 manages the process of adding / modifying functions across multiple project branches: Please refer to Figure 8 , Figure 8 This is another flowchart for managing multiple project branches provided in an embodiment of the present invention.

[0083] 1) If IP0 is added to the database under project A and then used in project B, and the IP maturity is updated during use (IP function is added or modified), then the IP will be uploaded to the database management system in project B. 2) In the uploaded IP management database, update the database entry name of IP0 (B_project_IP0_0.8) to record that IP0 is used in project B.

[0084] The hardware unit storage device, electronic device, computer-readable storage medium, and computer program product provided in the embodiments of the present invention will be described below. The hardware unit storage device, electronic device, computer-readable storage medium, and computer program product described below can be referred to in correspondence with the hardware unit storage method described above.

[0085] Please refer to Figure 9 , Figure 9 This invention provides a structural block diagram of a hardware unit storage device, which may include: The scanning module 901 is used to scan the project files of the hardware design project to determine the hardware units contained in the hardware design project and their information. The inbound form setting module 902 is used to determine the design verification maturity of the hardware unit based on the hardware unit information, and to set the inbound form of the hardware unit using the design verification maturity and hardware unit information. The inbound judgment module 903 is used to query the inbound form and determine whether there are hardware units whose design verification maturity meets the preset inbound conditions. The inbound verification module 904 is used to verify the hardware unit file of a hardware unit if the design verification maturity meets the preset inbound conditions, and to determine whether the hardware unit passes the verification. The inbound module 905 is used to add the hardware unit file and verification information of the hardware unit to the hardware unit management library and update the inbound identifier of the hardware unit to the inbound form if the hardware unit passes the verification.

[0086] Optionally, the scanning module 901 can be used for: The project files of the hardware design project are scanned to determine the hardware unit files and their project paths, and the information of the person in charge of the hardware unit is obtained. Determine the source type of the hardware unit based on the first keyword in the project path; The design verification version information of the hardware unit is determined based on the second keyword in the hardware unit file and / or the third keyword in the hardware unit file name. Based on the hardware unit file, determine the types of files already included in the hardware unit; Determine the unit type of the hardware unit based on the file extension of the hardware unit file; The hardware unit files are verified to obtain the verification coverage information of the hardware units.

[0087] Optionally, the inventory form settings module 902 can be used for: Based on preset conditions, determine the design verification maturity corresponding to the design verification version information, included file types, and verification coverage information.

[0088] Optionally, the device may further include: The periodic scanning module is used to periodically scan the project files of the hardware design project and determine whether the hardware unit information of the hardware unit has been updated; if the hardware unit information has been updated, the updated hardware unit information is used to update the hardware unit entry form.

[0089] Optionally, the inbound verification module 904 can be used for: Static and dynamic verification processes are performed on the hardware unit files to obtain the functional coverage log and code coverage log of the hardware unit. Based on the functional coverage log and code coverage log, determine whether the hardware unit has passed verification.

[0090] Optionally, the device may further include: The rollback backup module is used to determine whether the design verification maturity of a hardware unit has decreased based on the hardware unit's entry form. If the design verification maturity of a hardware unit has decreased, the module backs up the hardware unit files and verification information of the hardware unit in the hardware unit management library to the hardware unit backup library; or deletes the hardware unit files and verification information of the hardware unit in the hardware unit management library.

[0091] Optionally, the device may further include: The project branch management module is used to record the mapping relationship between the hardware unit and its source hardware design project and target hardware design project in the hardware unit management library if it is detected that the hardware unit has been introduced into another target hardware design project from the hardware unit management library; if it is determined that the hardware unit has been updated in the target hardware design project, and the design verification maturity of the hardware unit meets the preset entry conditions and the hardware unit has passed verification, then the hardware unit file and verification information of the hardware unit in the target hardware design project are added back to the hardware unit management library.

[0092] Please refer to Figure 10 , Figure 10 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. The present invention provides an electronic device 10, including a processor 11 and a memory 12; wherein, the memory 12 is used to store a computer program; the processor 11 is used to execute the hardware unit loading method provided in the foregoing embodiment when executing the computer program.

[0093] For details regarding the specific process of the above-mentioned hardware unit storage method, please refer to the relevant content provided in the foregoing embodiments, which will not be repeated here.

[0094] Furthermore, the memory 12, as a carrier for resource storage, can be a read-only memory, random access memory, disk, or optical disk, and the storage method can be temporary storage or permanent storage.

[0095] In addition, the electronic device 10 also includes a power supply 13, a communication interface 14, an input / output interface 15, and a communication bus 16; wherein, the power supply 13 is used to provide operating voltage for each hardware device on the electronic device 10; the communication interface 14 can create a data transmission channel between the electronic device 10 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this invention, and is not specifically limited here; the input / output interface 15 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0096] This invention also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the hardware unit warehousing method described in the above embodiments.

[0097] Since the embodiments of the computer program product section correspond to the embodiments of the hardware unit storage method section, please refer to the description of the embodiments of the hardware unit storage method section for the embodiments of the computer program product section, and they will not be repeated here.

[0098] This invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the hardware unit loading method described in the above embodiments.

[0099] Since the embodiments of the computer-readable storage medium portion correspond to the embodiments of the hardware unit storage method portion, the embodiments of the storage medium portion are described in the description of the embodiments of the hardware unit storage method portion, and will not be repeated here.

[0100] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0101] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0102] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0103] The foregoing has provided a detailed description of a hardware unit storage method, apparatus, electronic device, and storage medium provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of the present invention. It should be noted that those skilled in the art can make various improvements and modifications to the present invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the present invention.

Claims

1. A hardware unit warehousing method characterized by comprising: include: The project files of the hardware design project are scanned to determine the hardware units contained in the hardware design project and their information. The design verification maturity of the hardware unit is determined based on the hardware unit information, and the entry form of the hardware unit is set up using the design verification maturity and the hardware unit information. Query the inbound form to determine whether there are hardware units whose design verification maturity meets the preset inbound conditions; If a hardware unit has a design verification maturity that meets the preset inclusion conditions, then the hardware unit file of the hardware unit is verified, and it is determined whether the hardware unit passes the verification. If the hardware unit passes verification, the hardware unit file and verification information of the hardware unit are added to the hardware unit management library, and the entry identifier of the hardware unit is updated to the entry form.

2. The hardware unit warehousing method according to claim 1, characterized by, The process of scanning the project files of the hardware design project to determine the hardware units included in the hardware design project and their information includes: The project files of the hardware design project are scanned to determine the hardware unit files and project paths of the hardware units, and the person in charge of the hardware units is obtained. Based on the first keyword in the project path, determine the source type of the hardware unit; The design verification version information of the hardware unit is determined based on the second keyword in the hardware unit file and / or the third keyword in the hardware unit file name; Based on the hardware unit file, determine the file types already included in the hardware unit; The unit type of the hardware unit is determined based on the file extension of the hardware unit file; The hardware unit file is verified to obtain the verification coverage information of the hardware unit.

3. The hardware unit warehousing method according to claim 2, wherein, Determining the design verification maturity of the hardware unit based on the hardware unit information includes: Based on preset conditions, determine the design verification maturity corresponding to the design verification version information, the included file types, and the verification coverage information.

4. The hardware unit warehousing method according to claim 1, wherein, Also includes: The project files of the hardware design project are periodically scanned, and it is determined whether the hardware unit information of the hardware unit has been updated. If the hardware unit information is updated, the updated hardware unit information is used to update the entry form for the hardware unit.

5. The hardware unit warehousing method according to claim 1, wherein, The verification of the hardware unit file of the hardware unit includes: Static and dynamic verification processes are performed on the hardware unit files to obtain the functional coverage log and code coverage log of the hardware unit. Based on the functional coverage log and code coverage log, determine whether the hardware unit has passed verification.

6. The hardware unit storage method according to any one of claims 1 to 5, characterized in that, After adding the hardware unit file and verification information of the hardware unit to the hardware unit management library, the following is also included: Based on the hardware unit's inventory entry form, determine whether the design verification maturity of the hardware unit has decreased; If the design verification maturity of the hardware unit decreases, then the hardware unit file and verification information of the hardware unit in the hardware unit management library are backed up to the hardware unit backup library. Delete the hardware unit file and verification information of the hardware unit in the hardware unit management library.

7. The hardware unit storage method according to claim 6, characterized in that, Also includes: If it is detected that the hardware unit imports another target hardware design project from the hardware unit management library, then the mapping relationship between the hardware unit and the source hardware design project of the hardware unit and the target hardware design project is recorded in the hardware unit management library; If it is determined that the hardware unit has been updated in the target hardware design project, and the design verification maturity of the hardware unit meets the preset entry conditions and the hardware unit has passed verification, then the hardware unit file and verification information of the hardware unit in the target hardware design project will be re-added to the hardware unit management library.

8. A hardware unit warehousing device, characterized in that, include: The scanning module is used to scan the project files of the hardware design project to determine the hardware units contained in the hardware design project and their information. The inbound form setting module is used to determine the design verification maturity of the hardware unit based on the hardware unit information, and to set the inbound form of the hardware unit using the design verification maturity and the hardware unit information. The warehouse entry judgment module is used to query the warehouse entry form and determine whether there are hardware units whose design verification maturity meets the preset warehouse entry conditions. The entry verification module is used to verify the hardware unit file of a hardware unit if the design verification maturity meets the preset entry conditions, and to determine whether the hardware unit passes the verification. The entry module is used to add the hardware unit file and verification information of the hardware unit to the hardware unit management library and update the entry identifier of the hardware unit to the entry form if the hardware unit passes the verification.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the hardware unit loading method as described in any one of claims 1 to 7 when executing the computer program.

10. A non-volatile computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when loaded and executed by a processor, implement the hardware unit loading method as described in any one of claims 1 to 7.

Images