Heterogeneous core verification method and device, terminal, base station and chip

Abstract

The invention relates to a heterogeneous core verification method and device, a terminal, a base station and a chip. The method comprises the following steps: acquiring a configuration file corresponding to a to-be-analyzed chip; the configuration file at least comprises heterogeneous core parameters of heterogeneous cores in the to-be-analyzed chip; according to the configuration file, generating a directory file of a to-be-generated verification platform corresponding to the to-be-analyzed chip; generating a verification platform corresponding to the to-be-analyzed chip according to the directory file; and verifying the heterogeneous core in the to-be-analyzed chip through the verification platform to obtain a verification result of the heterogeneous core. By adopting the method, the verification convenience of the heterogeneous core can be improved.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a heterogeneous core verification method, apparatus, terminal, base station, chip, chip module, computer-readable storage medium, and computer program product. Background Technology

[0002] Currently, in order to ensure the overall stability of the SOC (System on Chip) chip, it is crucial to efficiently verify the heterogeneous cores in the SOC chip.

[0003] In traditional technologies, when verifying heterogeneous cores, each heterogeneous core typically builds an independent hardware and software co-verification platform in its own subsystem. However, these platforms are isolated from each other and incompatible, have poor code reusability, and are difficult to perform multi-core co-simulation, resulting in a lack of more realistic full-chip scenario verification, which in turn makes the verification of heterogeneous cores less convenient. Summary of the Invention

[0004] Therefore, it is necessary to provide a heterogeneous core verification method, device, terminal, base station, chip, chip module, computer-readable storage medium, and computer program product that can improve the convenience of heterogeneous core verification in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a heterogeneous kernel verification method, including:

[0006] Obtain the configuration file corresponding to the chip to be analyzed; the configuration file includes at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed;

[0007] Based on the configuration file, generate the directory file of the verification platform to be generated corresponding to the chip to be analyzed;

[0008] Based on the directory file, a verification platform corresponding to the chip to be analyzed is generated;

[0009] The heterogeneous core in the chip to be analyzed is verified using the verification platform, and the verification result of the heterogeneous core is obtained.

[0010] In one embodiment, generating the directory file of the verification platform corresponding to the chip to be analyzed, based on the configuration file, includes:

[0011] The configuration file is parsed to obtain the configuration parameters corresponding to the chip to be analyzed; the configuration parameters include at least the heterogeneous core parameters;

[0012] Obtain the directory file template of the verification platform to be generated corresponding to the chip to be analyzed, and add the configuration parameters to the corresponding position in the directory file template to obtain the directory file of the verification platform to be generated corresponding to the chip to be analyzed.

[0013] In one embodiment, before adding the configuration parameters to the corresponding position in the directory file template to obtain the directory file of the verification platform to be generated corresponding to the chip to be analyzed, the method further includes:

[0014] Extract the required configuration parameters from the configuration parameters;

[0015] The required configuration parameters are subjected to non-empty validation to obtain the validation result;

[0016] The step of adding the configuration parameters to the corresponding position in the directory file template to obtain the directory file of the verification platform to be generated for the chip to be analyzed includes:

[0017] If the verification result indicates that the required configuration parameter is not empty, the configuration parameter is added to the corresponding position in the directory file template to obtain the directory file of the verification platform to be generated corresponding to the chip to be analyzed.

[0018] In one embodiment, generating the verification platform corresponding to the chip to be analyzed based on the directory file includes:

[0019] Based on the configuration file, the directory file is modified to obtain the modified directory file;

[0020] Based on the modified directory file, a verification platform corresponding to the chip to be analyzed is generated.

[0021] In one embodiment, before verifying the heterogeneous core in the chip to be analyzed through the verification platform and obtaining the verification result of the heterogeneous core, the method further includes:

[0022] From the directory file, obtain the basic use cases corresponding to the heterogeneous cores in the chip to be analyzed;

[0023] The basic test case is executed in the verification platform to obtain the simulation results corresponding to the basic test case.

[0024] The process of verifying the heterogeneous cores in the chip to be analyzed through the verification platform to obtain the verification results of the heterogeneous cores includes:

[0025] If the simulation results corresponding to the basic use case indicate that the simulation of the basic use case is successful, the heterogeneous core in the chip to be analyzed is verified through the verification platform to obtain the verification result of the heterogeneous core.

[0026] In one embodiment, when the simulation result corresponding to the basic use case indicates that the basic use case simulation has passed, the heterogeneous core in the chip to be analyzed is verified through the verification platform to obtain the verification result of the heterogeneous core, including:

[0027] If the simulation result corresponding to the basic use case indicates that the basic use case simulation is successful, configure the use case parameters corresponding to the heterogeneous core according to the verification method corresponding to the heterogeneous core.

[0028] Based on the use case parameters, generate the target use case corresponding to the heterogeneous core;

[0029] The target use case is executed in the verification platform to obtain the simulation results of the target use case;

[0030] Based on the simulation results of the target use case, the verification results of the heterogeneous core are obtained.

[0031] Secondly, this application also provides a heterogeneous core verification device, comprising:

[0032] The file acquisition module is used to acquire the configuration file corresponding to the chip to be analyzed; the configuration file includes at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed;

[0033] The file generation module is used to generate a directory file of the verification platform corresponding to the chip to be analyzed, based on the configuration file.

[0034] The platform generation module is used to generate a verification platform corresponding to the chip to be analyzed based on the directory file.

[0035] The heterogeneous core verification module is used to verify the heterogeneous core in the chip to be analyzed through the verification platform, and obtain the verification result of the heterogeneous core.

[0036] Thirdly, this application also provides a terminal, including a memory, a processor, a main camera, and a secondary camera. The memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0037] Obtain the configuration file corresponding to the chip to be analyzed; the configuration file includes at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed;

[0038] Based on the configuration file, generate the directory file of the verification platform to be generated corresponding to the chip to be analyzed;

[0039] Based on the directory file, a verification platform corresponding to the chip to be analyzed is generated;

[0040] The heterogeneous core in the chip to be analyzed is verified using the verification platform, and the verification result of the heterogeneous core is obtained.

[0041] Fourthly, this application also provides a base station, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0042] Obtain the configuration file corresponding to the chip to be analyzed; the configuration file includes at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed;

[0043] Based on the configuration file, generate the directory file of the verification platform to be generated corresponding to the chip to be analyzed;

[0044] Based on the directory file, a verification platform corresponding to the chip to be analyzed is generated;

[0045] The heterogeneous core in the chip to be analyzed is verified using the verification platform, and the verification result of the heterogeneous core is obtained.

[0046] Fifthly, this application also provides a chip, the chip including at least one processor, which, when executing the computer program, performs the following steps:

[0047] Obtain the configuration file corresponding to the chip to be analyzed; the configuration file includes at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed;

[0048] Based on the configuration file, generate the directory file of the verification platform to be generated corresponding to the chip to be analyzed;

[0049] Based on the directory file, a verification platform corresponding to the chip to be analyzed is generated;

[0050] The heterogeneous core in the chip to be analyzed is verified using the verification platform, and the verification result of the heterogeneous core is obtained.

[0051] Sixthly, this application also provides a chip module coupled to a memory, which, when executing a computer program stored in the memory, performs the following steps:

[0052] Obtain the configuration file corresponding to the chip to be analyzed; the configuration file includes at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed;

[0053] Based on the configuration file, generate the directory file of the verification platform to be generated corresponding to the chip to be analyzed;

[0054] Based on the directory file, a verification platform corresponding to the chip to be analyzed is generated;

[0055] The heterogeneous core in the chip to be analyzed is verified using the verification platform, and the verification result of the heterogeneous core is obtained.

[0056] Seventhly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0057] Obtain the configuration file corresponding to the chip to be analyzed; the configuration file includes at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed;

[0058] Based on the configuration file, generate the directory file of the verification platform to be generated corresponding to the chip to be analyzed;

[0059] Based on the directory file, a verification platform corresponding to the chip to be analyzed is generated;

[0060] The heterogeneous core in the chip to be analyzed is verified using the verification platform, and the verification result of the heterogeneous core is obtained.

[0061] Eighthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0062] Obtain the configuration file corresponding to the chip to be analyzed; the configuration file includes at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed;

[0063] Based on the configuration file, generate the directory file of the verification platform to be generated corresponding to the chip to be analyzed;

[0064] Based on the directory file, a verification platform corresponding to the chip to be analyzed is generated;

[0065] The heterogeneous core in the chip to be analyzed is verified using the verification platform, and the verification result of the heterogeneous core is obtained.

[0066] The aforementioned heterogeneous core verification method, apparatus, terminal, base station, chip, chip module, computer-readable storage medium, and computer program product first obtain the configuration file corresponding to the chip to be analyzed; the configuration file includes at least the heterogeneous core parameters of the heterogeneous cores in the chip to be analyzed; then, based on the configuration file, a directory file for generating a verification platform corresponding to the chip to be analyzed is generated; next, based on the directory file, a verification platform corresponding to the chip to be analyzed is generated; finally, the heterogeneous cores in the chip to be analyzed are verified through the verification platform to obtain the verification results of the heterogeneous cores. In this way, when verifying heterogeneous cores, by using a configuration file that includes at least the heterogeneous core parameters of the heterogeneous cores in the chip under analysis as a single data source, a directory file for a verification platform to be generated for the chip under analysis can be specifically generated. This allows for the automatic generation of a verification platform that matches the chip under analysis, and then unified verification of the heterogeneous cores in the chip under analysis can be performed based on this verification platform, which helps to improve the convenience of heterogeneous core verification. Moreover, it avoids the shortcomings of traditional technology, which uses verification platforms built on the subsystems of each heterogeneous core, which easily leads to a lack of more realistic full-chip scenario verification and thus results in low convenience of heterogeneous core verification. This further improves the convenience of heterogeneous core verification. Attached Figure Description

[0067] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0068] Figure 1 This is a flowchart illustrating a heterogeneous kernel verification method in one embodiment;

[0069] Figure 2 This is a flowchart illustrating the heterogeneous kernel verification method in another embodiment;

[0070] Figure 3 This is a schematic diagram of a heterogeneous core unified verification architecture in one embodiment;

[0071] Figure 4 This is a schematic diagram of the structure of the USVP (Unified Subsystem Verification Platform) platform catalog in one embodiment;

[0072] Figure 5 This is a schematic diagram of the structure of the env (Environment, verification environment) directory in one embodiment;

[0073] Figure 6This is a schematic diagram of the structure of the sw (Software) directory in one embodiment;

[0074] Figure 7 This is a schematic diagram of the structure of the utils (Utilities) directory in one embodiment;

[0075] Figure 8 This is a structural block diagram of a heterogeneous core verification device in one embodiment;

[0076] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0077] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0078] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0079] In one exemplary embodiment, such as Figure 1 As shown, a heterogeneous core verification method is provided. This embodiment illustrates the application of this method to a server. It is understood that this method can also be applied to terminals, systems including terminals and servers, and implemented through interaction between the terminal and server. It can also be applied to base stations, chips, and chip modules. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, and tablets; the server can be a standalone server or a server cluster composed of multiple servers. In this embodiment, the method includes the following steps:

[0080] Step S101: Obtain the configuration file corresponding to the chip to be analyzed; the configuration file shall include at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed.

[0081] Among them, the chip to be analyzed refers to the chip that needs to be verified.

[0082] The configuration file refers to a file that records various parameters of the chip to be analyzed, including heterogeneous core parameters of the heterogeneous cores in the chip to be analyzed, memory configuration parameters of the chip to be analyzed, hardware and software interaction base address parameters, chip-level architecture parameters, toolchain configuration parameters, etc.

[0083] Heterogeneous cores refer to computing units with different architectures and functions in the chip being analyzed.

[0084] Among them, heterogeneous core parameters refer to various indicators that describe the specific characteristics of heterogeneous cores, including core basic parameters (including the number of cores, the type of bus master interface for cores to access external networks, bus address width, and bus data width), core architecture parameters (including instruction set platform and microarchitecture version), stack and memory parameters (including stack space configuration parameters), interrupt configuration parameters (including interrupt controller configuration parameters), and code storage parameters (including instruction file storage configuration).

[0085] For example, in response to a verification platform generation instruction for the chip to be analyzed, the server obtains the heterogeneous core parameters, memory configuration parameters, hardware-software interaction base address parameters, chip-level architecture parameters, and toolchain configuration parameters of the heterogeneous core in the chip to be analyzed from the chip design document of the chip to be analyzed; then, the server generates a configuration file corresponding to the chip to be analyzed according to a preset file format, based on the heterogeneous core parameters, memory configuration parameters, hardware-software interaction base address parameters, chip-level architecture parameters, and toolchain configuration parameters.

[0086] Step S102: Generate the directory file of the verification platform corresponding to the chip to be analyzed according to the configuration file.

[0087] Among them, the verification platform to be generated refers to the verification platform planned to be generated based on the configuration file.

[0088] The directory file refers to the list file that records the file paths and directory structure in the verification platform to be generated.

[0089] For example, the server extracts the configuration parameters from the configuration file; then, the server generates a directory file corresponding to the directory file template and configuration parameters of the verification platform to be generated, according to the directory file template of the chip to be analyzed and the configuration parameters in the configuration file, and uses it as the directory file of the verification platform to be generated.

[0090] Step S103: Generate the verification platform corresponding to the chip to be analyzed based on the directory file.

[0091] The verification platform refers to the verification platform actually generated based on the directory file.

[0092] For example, the server parses the directory file to obtain the directory path information and file path information in the directory file; then, the server performs integrity verification on the directory path information and file path information in the directory file to obtain the corresponding verification result; if the verification result indicates that the directory path information and file path information in the directory file are complete, the server generates the verification platform corresponding to the chip to be analyzed according to the directory path information and file path information in the directory file.

[0093] Step S104: The heterogeneous core in the chip to be analyzed is verified through the verification platform to obtain the verification result of the heterogeneous core.

[0094] The verification results are used to express conclusive information on whether the heterogeneous core meets the design requirements. These include basic function verification results (whether the core functions of the heterogeneous core are normal, such as instruction execution, data operation, interrupt response, bus interaction, multi-core collaboration, etc., and whether they meet the design specifications; whether there are functional defects, such as calculation errors, communication lag, interrupt loss, etc.), compliance verification results (whether the heterogeneous core meets the preset indicators, such as performance meeting the standards and power consumption within a reasonable range), and compatibility verification results (whether the compatibility with other components is normal, and whether there are adaptation problems).

[0095] For example, in response to a basic function verification command for a heterogeneous core, the server performs basic function verification on the heterogeneous core in the chip to be analyzed through a verification platform, and obtains the basic function verification result of the heterogeneous core; in response to a compliance verification command for a heterogeneous core, the server performs compliance verification on the heterogeneous core in the chip to be analyzed through a verification platform, and obtains the compliance verification result of the heterogeneous core; in response to a compatibility verification command for a heterogeneous core, the server performs compatibility verification on the heterogeneous core in the chip to be analyzed through a verification platform, and obtains the compatibility verification result of the heterogeneous core; then, the server uses the basic function verification result, compliance verification result, and compatibility verification result of the heterogeneous core as the verification result of the heterogeneous core.

[0096] In the above heterogeneous core verification method, the configuration file corresponding to the chip to be analyzed is first obtained. The configuration file includes at least the heterogeneous core parameters of the heterogeneous cores in the chip to be analyzed. Then, based on the configuration file, a directory file for the verification platform to be generated corresponding to the chip to be analyzed is generated. Next, based on the directory file, the verification platform corresponding to the chip to be analyzed is generated. Finally, the heterogeneous cores in the chip to be analyzed are verified through the verification platform to obtain the verification results of the heterogeneous cores. In this way, when verifying heterogeneous cores, by using the configuration file, which includes at least the heterogeneous core parameters of the heterogeneous cores in the chip to be analyzed, as a single data source, a directory file for the verification platform to be generated corresponding to the chip to be analyzed can be generated specifically. This allows for the automatic generation of a verification platform that matches the chip to be analyzed. Then, based on this verification platform, the heterogeneous cores in the chip to be analyzed can be uniformly verified, which is beneficial to improving the convenience of heterogeneous core verification. Moreover, it avoids the shortcomings of traditional technologies that use verification platforms built in the subsystems of each heterogeneous core, which easily leads to a lack of more realistic full-chip scenario verification and thus results in low convenience of heterogeneous core verification. This further improves the convenience of heterogeneous core verification.

[0097] In an exemplary embodiment, step S102 above, which generates a directory file of the verification platform corresponding to the chip to be analyzed according to the configuration file, specifically includes the following: parsing the configuration file to obtain the configuration parameters corresponding to the chip to be analyzed; the configuration parameters include at least heterogeneous core parameters; obtaining the directory file template of the verification platform corresponding to the chip to be analyzed, adding the configuration parameters to the corresponding positions in the directory file template, and obtaining the directory file of the verification platform corresponding to the chip to be analyzed.

[0098] The configuration parameters refer to all parameters in the configuration file, including heterogeneous core parameters of the heterogeneous core in the chip to be analyzed, memory configuration parameters of the chip to be analyzed, hardware and software interaction base address parameters, chip-level architecture parameters, toolchain configuration parameters, etc.

[0099] The directory file template refers to the pre-defined manifest file framework for the verification platform to be generated, which includes the general directory structure and file path placeholders for the verification platform to be generated.

[0100] The corresponding location refers to the placeholder or specific area in the directory file template that matches the configuration parameters. For example, the directory file template reuse / cpu_monitor / Placeholders in _mon_intf.sv It needs to be replaced with the corresponding value in the configuration parameter BUS_TYPE (such as "axi" or "ahb") to ensure that the generated directory file can accurately reflect the heterogeneous characteristics of the chip.

[0101] For example, the server uses a parsing tool to parse the configuration file to obtain the heterogeneous core parameters, memory configuration parameters, hardware / software interaction base address parameters, chip-level architecture parameters, and toolchain configuration parameters of the heterogeneous core in the chip to be analyzed, which are used as the configuration parameters corresponding to the chip to be analyzed. Then, according to the chip type of the chip to be analyzed (such as a SOC chip), the server calls the directory file template corresponding to the chip type from the template library as the directory file template for the verification platform to be generated corresponding to the chip to be analyzed. Then, according to the corresponding position of the configuration parameters in the directory file template, the server adds the configuration parameters to the corresponding position in the directory file template to obtain the directory file of the verification platform to be generated corresponding to the chip to be analyzed.

[0102] In this embodiment, by first parsing the configuration file to extract the core characteristics of the chip, and then accurately filling in the parameters based on the exclusive directory file template, the repetitive workload of manually building the directory file and the parameter matching errors are effectively reduced, the efficiency and accuracy of directory file generation are improved, and a solid foundation is laid for the subsequent rapid and reliable generation of a complete verification platform.

[0103] In an exemplary embodiment, before adding the configuration parameters to the corresponding position in the directory file template to obtain the directory file of the verification platform to be generated for the chip to be analyzed, the following steps are specifically included: extracting the mandatory configuration parameters from the configuration parameters; performing non-empty verification processing on the mandatory configuration parameters to obtain the verification result.

[0104] Then, add the configuration parameters to the corresponding position in the directory file template to obtain the directory file of the verification platform to be generated for the chip to be analyzed. Specifically, it includes the following: if the verification result indicates that the required configuration parameters are not empty, add the configuration parameters to the corresponding position in the directory file template to obtain the directory file of the verification platform to be generated for the chip to be analyzed.

[0105] Among them, the required configuration parameters are those necessary for generating the directory file. These include, for example, the subsystem name (subsys_name), bus type (BUS_TYPE), and number of cores (CORE_NUM) for heterogeneous cores. These parameters directly determine the generation of critical paths in the directory file (such as subsystem-specific directories and bus monitoring file paths), and are the foundation for template filling and structure construction.

[0106] The verification result refers to the conclusive information output after performing non-empty verification on the required configuration parameters, including whether the required configuration parameter is non-empty (a valid value exists) or whether the required configuration parameter is empty (undefined or invalid value).

[0107] For example, the server determines a list of pre-defined mandatory configuration parameters for the chip to be analyzed based on its chip type. Then, the server extracts the mandatory configuration parameters from this list. Next, the server determines the non-empty validation rules for each mandatory configuration parameter based on its parameter type. For example, for string type parameters, the non-empty rule is "the value cannot be null, an empty string (""), or a string containing only spaces." For numeric type parameters, the non-empty rule not only requires the value to be not null but also to conform to business logic (e.g., CORE_NUM must be a positive integer, not 0 or negative; RAM_SIZE must be greater than 0, not 0 or negative). Next, the server performs non-empty validation on the mandatory configuration parameters according to the corresponding non-empty validation rules, obtaining the validation results. If the validation results indicate that all mandatory configuration parameters are non-empty, the server adds the configuration parameters to the corresponding position in the directory file template, obtaining the directory file for the verification platform to be generated for the chip to be analyzed.

[0108] In this embodiment, by accurately extracting the core parameters necessary for generating the verification platform and performing non-empty checks, problems such as missing, empty, or invalid parameters in the configuration file can be detected in advance. This avoids subsequent directory file template filling failures, incomplete verification platform structure, or functional abnormalities due to incomplete key parameters, thus ensuring the reliability of the subsequent verification platform generation process.

[0109] In an exemplary embodiment, step S103 above, generating a verification platform corresponding to the chip to be analyzed based on the directory file, specifically includes the following: modifying the directory file according to the configuration file to obtain a modified directory file; generating a verification platform corresponding to the chip to be analyzed based on the modified directory file.

[0110] The modified directory file refers to the directory file created after modifications (such as adjustments, additions, or deletions) to the configuration parameters in the configuration file. For example, the bus type (e.g., BUS_TYPE, used to specify the exact type of the AMBA bus) and subsystem name (e.g., subsys_name, used to determine the subsystem name) in the heterogeneous core parameters of the configuration file may be modified. <subsys>(Specific values), modify the include_ in the top (top-level directory) directory. <subsys>The _test_top.sv file can be modified, for example, to connect the AMBA (Advanced Microcontroller Bus Architecture) bus interface of the cpu_monitor (CPU monitor) to the AMBA bus interface of the CORE (core).

[0111] For example, the server parses the configuration file to obtain the configuration parameters. Then, the server inputs the configuration parameters into the trained importance prediction model to obtain the predicted importance of each configuration parameter. Next, the server selects configuration parameters whose predicted importance is greater than a preset importance as key configuration parameters (i.e., configuration parameters affecting the directory file). Then, based on the key configuration parameters, the server queries the correspondence between the configuration parameters and the directory file modification rules to obtain the directory file modification rules corresponding to the key configuration parameters. Then, the server modifies the directory file according to the directory file modification rules corresponding to the key configuration parameters to obtain the modified directory file. Next, the server parses the modified directory file to obtain the directory path information and file path information within it. Next, the server performs integrity verification on the directory path information and file path information in the modified directory file to obtain the corresponding verification result. If the verification result indicates that the directory path information and file path information in the modified directory file are complete, the server generates a verification platform corresponding to the chip to be analyzed based on the directory path information and file path information in the modified directory file.

[0112] In this embodiment, by modifying the directory files in a way that drives the configuration file, the directory structure can be accurately adapted to the characteristics of the chip being analyzed, avoiding redundant or missing paths. Then, based on the modified directory files, a verification platform can be generated, which can directly build a verification environment that is highly matched to the characteristics of the chip, thus ensuring the customization of the verification platform.

[0113] In an exemplary embodiment, before verifying the heterogeneous core in the chip to be analyzed through the verification platform and obtaining the verification result of the heterogeneous core, step S104 specifically includes the following: obtaining the basic use case corresponding to the heterogeneous core in the chip to be analyzed from the directory file; executing the basic use case in the verification platform and obtaining the simulation result corresponding to the basic use case.

[0114] Therefore, step S104 above, which verifies the heterogeneous core in the chip to be analyzed through the verification platform, and obtains the verification result of the heterogeneous core, specifically includes the following: if the simulation result corresponding to the basic use case indicates that the basic use case simulation is passed, the heterogeneous core in the chip to be analyzed is verified through the verification platform, and the verification result of the heterogeneous core is obtained.

[0115] Among them, basic test cases refer to the test cases (such as the hello_world test case) that are preset in the directory file to verify the basic functions of heterogeneous cores.

[0116] The simulation results of the basic test cases refer to the conclusive information output after running the basic test cases in the verification platform, including whether the basic test case simulation passed or failed.

[0117] For example, the server determines the use case files in the directory file; then, based on the core type corresponding to the heterogeneous core in the chip to be analyzed, the server obtains the basic use cases corresponding to the core type from the use case files, as the basic use cases corresponding to the heterogeneous core; then, the server executes the basic use cases in the verification platform according to the execution rules (such as execution priority) of the basic use cases, and obtains the simulation results corresponding to the basic use cases; if the simulation results corresponding to the basic use cases indicate that the simulation of the basic use cases has passed, the server verifies the heterogeneous core in the chip to be analyzed through the verification platform, and obtains the verification results of the heterogeneous core.

[0118] In this embodiment, by accurately obtaining basic use cases specific to heterogeneous cores from the directory file, the initial verification of core functions can be quickly completed by relying on the verification platform. The simulation results can intuitively determine whether the heterogeneous core has core capabilities such as normal startup and basic instruction execution, avoiding the ineffective costs caused by directly carrying out complex verification, clearing obstacles for a more comprehensive verification process in the future, and ensuring the efficiency and pertinence of the overall verification work.

[0119] In an exemplary embodiment, if the simulation result corresponding to the basic use case indicates that the basic use case simulation has passed, the heterogeneous core in the chip to be analyzed is verified through the verification platform to obtain the verification result of the heterogeneous core. Specifically, this includes the following: if the simulation result corresponding to the basic use case indicates that the basic use case simulation has passed, configuring the use case parameters corresponding to the heterogeneous core according to the verification method corresponding to the heterogeneous core; generating the target use case corresponding to the heterogeneous core according to the use case parameters; executing the target use case in the verification platform to obtain the simulation result of the target use case; and obtaining the verification result of the heterogeneous core based on the simulation result of the target use case.

[0120] The verification method refers to the specific way to verify heterogeneous cores, including individual verification and collaborative verification.

[0121] Among them, use case parameters refer to the core configuration data used to generate target use cases. It should be noted that the use case parameters for heterogeneous cores configured for individual verification and collaborative verification are different. For individual verification, use case parameters include functional verification parameters (such as the instruction set to be covered, the range of independently accessed memory addresses, and the types of exceptions to be triggered) and performance verification parameters (such as single-core continuous runtime and single-core load intensity). For collaborative verification, use case parameters include data interaction parameters (such as shared memory addresses between cores and data synchronization mechanisms), task scheduling parameters (such as task allocation and inter-core communication interfaces), and conflict handling parameters (such as bus contention arbitration methods).

[0122] Among them, target use cases refer to specific test cases for the specific verification requirements of heterogeneous cores.

[0123] The simulation result of the target use case refers to the conclusive information output after running the target use case in the verification platform, including whether the target use case simulation passed or failed.

[0124] For example, if the simulation result corresponding to the basic use case indicates that the basic use case simulation has passed, the server responds to the verification instruction for the heterogeneous core and determines the verification method corresponding to the heterogeneous core according to the verification instruction. Then, based on the verification method corresponding to the heterogeneous core, the server queries the correspondence between the verification method and the use case parameters to obtain and configure the use case parameters corresponding to the heterogeneous core. Then, the server adds the use case parameters to the corresponding position in the use case template to obtain the target use case corresponding to the heterogeneous core. Next, the server executes the target use case in the verification platform according to the verification instruction of the heterogeneous core to obtain the simulation result of the target use case. Finally, the server uses the simulation result based on the target use case as the verification result of the heterogeneous core.

[0125] In this embodiment, by executing the target use case and analyzing the simulation results, the performance of the heterogeneous core in a specific scenario can be comprehensively and accurately fed back. This not only ensures the depth and completeness of the verification, but also enables the rapid location of potential defects through structured results, ultimately providing a reliable basis for whether the heterogeneous core meets the design requirements, thus supporting the efficiency and accuracy of chip verification work.

[0126] In one exemplary embodiment, such as Figure 2 As shown, another heterogeneous core verification method is provided. Taking the application of this method to a server as an example, the specific steps include:

[0127] Step S201: Obtain the configuration file corresponding to the chip to be analyzed; the configuration file shall include at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed.

[0128] Step S202: Parse the configuration file to obtain the configuration parameters corresponding to the chip to be analyzed; the configuration parameters include at least the heterogeneous core parameters.

[0129] Step S203: Obtain the directory file template of the verification platform to be generated corresponding to the chip to be analyzed.

[0130] Step S204: Extract the mandatory configuration parameters from the configuration parameters; perform non-empty verification on the mandatory configuration parameters to obtain the verification result.

[0131] Step S205: If the verification result indicates that the required configuration parameters are not empty, add the configuration parameters to the corresponding position in the directory file template to obtain the directory file of the verification platform to be generated for the chip to be analyzed.

[0132] Step S206: Modify the directory file according to the configuration file to obtain the modified directory file.

[0133] Step S207: Generate the verification platform corresponding to the chip to be analyzed based on the modified directory file.

[0134] Step S208: Obtain the basic use cases corresponding to the heterogeneous cores in the chip to be analyzed from the directory file; execute the basic use cases in the verification platform to obtain the simulation results corresponding to the basic use cases.

[0135] Step S209: If the simulation result corresponding to the basic use case indicates that the basic use case simulation has passed, configure the use case parameters corresponding to the heterogeneous core according to the verification method corresponding to the heterogeneous core.

[0136] Step S210: Generate target use cases corresponding to heterogeneous cores based on use case parameters; execute target use cases in the verification platform to obtain simulation results of target use cases; obtain verification results of heterogeneous cores based on simulation results of target use cases.

[0137] In the aforementioned heterogeneous core verification method, when verifying heterogeneous cores, a configuration file containing at least the heterogeneous core parameters of the heterogeneous cores in the chip under analysis is used as a single data source. This allows for the generation of a directory file for a verification platform corresponding to the chip under analysis, thereby automatically generating a verification platform that matches the chip under analysis. Based on this verification platform, the heterogeneous cores in the chip under analysis can be uniformly verified, which improves the convenience of heterogeneous core verification. Moreover, it avoids the shortcomings of traditional technologies that use verification platforms built in the subsystems of each heterogeneous core, which can easily lead to a lack of more realistic full-chip scenario verification and thus result in low convenience of heterogeneous core verification. This further improves the convenience of heterogeneous core verification.

[0138] In an exemplary embodiment, to more clearly illustrate the heterogeneous core verification method provided in this application, the following specific embodiment will be used to describe the heterogeneous core verification method in detail. In one embodiment, this application also provides a unified verification platform and method applicable to heterogeneous cores. Specifically, it includes the following:

[0139] I. Introduction to the USVP Platform:

[0140] In USVP, multiple different Core Subsystems share a single platform architecture, basic software libraries, and hardware task libraries. All cores are shared to improve reusability, supporting both individual subsystem simulation and multi-system co-simulation. Figure 3 As shown.

[0141] like Figure 4 As shown, the overall directory structure of the UVSP platform is as follows:

[0142] The Bin (Binary) directory defines cfg (Configuration) files, which contain common (general directory) configurations, include (reference) configurations, different subsys use case configurations, and vip (Verification IP) configurations.

[0143] The `env` directory primarily contains basic UVM (Universal Verification Methodology) components, such as `cfg`, `pkg` (Package), and `vseqr` (Virtual Sequencer). Many interface VIPs are often UVM VIPs. To enable joint debugging between IPs and real cores in UVSP, a basic UVM framework has been implemented for integrating UVM VIPs. The `env` directory also includes configuration files such as `usvp_env_cfg.sv` (a verification environment configuration file), `usvp_env_pkg.svi` (a verification environment configuration file), `usvp_env.sv` (a verification environment configuration file), and `usvp_vseqr.sv` (a verification environment configuration file). Figure 5 As shown.

[0144] The file in the flist(File List) directory is usvp.vc.

[0145] The inc (Include, Reference Directory) directory mainly contains commonly used macro definition files.

[0146] The regression directory contains a list of case regressions, which are used for large-scale case regressions.

[0147] The sva (System Verilog Assertion) field contains the assertion file and its instantiation, which checks the correctness of the simulation behavior during simulation.

[0148] The `sw` directory defines the software architecture, currently supporting the ARM (Advanced RISC Machines) platform and the RISC-V (Reduced Instruction Set Computing-V) platform. Figure 6 As shown.

[0149] ARM / RISCV: The ARM platform can be further divided into the Cortex-A (a heterogeneous core) series, Cortex-M (a heterogeneous core) series, and Cortex-R series based on different architectures. The software structure of different architectures is divided into three parts:

[0150] boot (boot directory): Stores boot-related code, usually in assembly format.

[0151] link (linking script directory): Stores linked files.

[0152] common: Architecture-specific function library.

[0153] sub.mk (Sub-Makefile): Architecture-specific makefile.

[0154] driver (driver directory): This directory contains commonly used IP driver libraries. These drivers are usable on all architectures. Currently, the following drivers have been implemented:

[0155] DMA (Direct Memory Access) / GPIO (General Purpose Input / Output) / IIC (Inter-Integrated Circuit) / IIS (Inter-IC Sound) / Mailbox (Mailbox Communication) / SPI (Serial Peripheral Interface) / THM (Thermal Control) / Timer (Timer) / UART (Universal Asynchronous Receiver / Transmitter) / Watchdog (Watchdog Timer) / UFS (Universal Flash Storage) / DDR (Double Data Rate) etc.

[0156] common: This directory contains platform-related functions that can be shared across all architectures, such as mmio (Memory-Mapped Input / Output) functions for address reading and writing, print (Print Function) functions for printing, SOC-related functions, and hardware / software interaction functions.

[0157] script (script directory): contains the bin2hex.pl script (Binary to Hexadecimal Perl Script).

[0158] Makefile (compilation file): A makefile script that is common to all architectures.

[0159] The tests directory is mainly used to store test cases, with different test cases stored in different directories.

[0160] The `top` directory primarily stores top-level modules and VIP bind files. The top-level module of the platform is defined in `usvp / top / usvp_test_top.sv` (the top-level file for the unified subsystem verification platform test). This module is bound to `tb_top` (the top-level test platform). Then, custom hardware code from different subsystems is included using macros to separate them. Shared content within this `top` file includes:

[0161] (1) Instantiation of the test case SV (SystemVerilog) part and execution of run_test (execute test);

[0162] (2) FDMA (Flash Direct Memory Access) related initialization and related tasks;

[0163] (3) Instantiation and initialization of CXDT bench (a test platform for simulation verification);

[0164] (4) Heartbeat process used to monitor program execution time and TIMEOUT check.

[0165] The utils directory mainly stores the CPU (Central Processing Unit) monitoring module and some tasks, such as... Figure 7 As shown:

[0166] reuse / cpu_monitor: CPU monitoring class used for FLAG printing and printf printing. The cpu_monitor and factory functions used to monitor the CPU for string printing and FLAG printing are shared by all subsys.

[0167] The cpu_monitor includes ahb_mon_intf.sv (a bus monitoring interface file), axi_mon_intf.sv (a bus monitoring interface file), cpu_monitor.sv (a monitor implementation file), and cpu_monitor.pkg (CPU monitor package).

[0168] reuse / sprd_factory (Spreadtrum factory class): Factory class used for creating the use case SV part.

[0169] Among them, sprd_factory includes sprd_factory.sv (the Spreadtrum factory class implementation file).

[0170] Tasks (task sets): Platform-specific tasks, defining tasks common to all subsys, such as common_task.sv (general task file), low_power_task_lib.sv (low-power task library file), and apcpu_task.sv (apcpu_task.sv (application processor task file), specifically including the following:

[0171] (1) set_flag (set flag) / get_flag (get flag) / wait_flag (wait flag) task;

[0172] (2) set_share (set share) / get_share (get share) task;

[0173] (3) get_boot_cnt (get boot count) / wait_boot_cnt (wait for boot count) task;

[0174] (4) DDR (ddr backdoor access) backdoor access related tasks;

[0175] (5) sprd_split_string (Spreadtrum string splitting) task;

[0176] (6) Some IPs configure tasks through BFM (Bus Functional Model).

[0177] II. Automated script implementation methods and processes:

[0178] To quickly set up a USVP verification platform and accelerate the iteration process, a script was developed to generate the USVP verification environment. The script usage is described below:

[0179] The meanings of each option are as follows:

[0180] -c CONFIG (configuration): A JSON (JavaScript Object Notation) format configuration file used to obtain some basic information for generating the USVP environment framework.

[0181] -o OUTPUT (output): Path to the output environment. If not specified, it will be generated in the default path.

[0182] -t: Whether to generate test cases. If -t is used, existing test cases will be copied to the tests directory.

[0183] Before using this script to generate the environment, the owner (responsible person) needs to verify that they have modified the configuration file according to the actual project. This configuration file mainly describes some architecture-related information, such as the number of CPU cores, GIC (Generic Interrupt Controller) base address, RAM (Random Access Memory) base address and size, DDR base address and size, ROM (Read-Only Memory) base address and size, etc.

[0184] The JSON configuration format parameters are as follows:

[0185] With CORE subsystem:

[0186] CORE_NUM: Number of cores (required parameter).

[0187] BUS_TYPE: The type of bus master port that the Core accesses for printing monitoring. It only supports AXI (Advanced eXtensible Interface) or AHB (Advanced High-performance Bus) (required parameter).

[0188] BUS_ADDR_WIDTH: Describes the width of the printed monitoring bus address (required parameter).

[0189] BUS_DATA_WIDTH: Describes the data to be printed from the monitoring bus (required parameter).

[0190] Core-related parameters:

[0191] PLATFROM: Indicates the CORE instruction set, such as ARM or RISC (required parameter).

[0192] ARCH: Indicates the instruction set microarchitecture of the CORE. For example, ARM supports armv7-r (an instruction set microarchitecture), armv8-r (an instruction set microarchitecture), armv8-m (an instruction set microarchitecture), armv8-a (an instruction set microarchitecture), armv9-a (an instruction set microarchitecture), etc., while RSICV supports dory (an instruction set microarchitecture), e906 (an instruction set microarchitecture), etc. (Required parameter).

[0193] STACKHEAP: Describes the stack space (optional parameter).

[0194] ADDR: Stack base address.

[0195] SIZE: Stack size.

[0196] INTERRUPT: Describes interrupt-related parameters (optional).

[0197] VERSION: Interrupt version, such as GICv3 (Generic Interrupt Controller version 3) / NVIC (Nested Vectored Interrupt Controller), etc.

[0198] BASE: Base address of the interrupt register.

[0199] MAX_SPI_NUM: Maximum number of interrupts.

[0200] CODE_PLACE: Describes the location where the command hex (hexadecimal) file is stored (optional parameter).

[0201] SUBSYS: The subsystem that is stored.

[0202] RAM_TYPE: The type of RAM stored, supporting both RAM and ROM.

[0203] Without CORE subsystem:

[0204] ROM / RAM: Describes the address and size of RAM / ROM within this subsystem (required parameter).

[0205] BASE: The base address of ROM / RAM.

[0206] SIZE: Size of ROM / RAM.

[0207] WIDTH: ROM / RAM bit width.

[0208] GRANULARITY: ROM / RAM granularity.

[0209] HW_SW_SHARE_BASE: Specifies the base address for hardware and software interaction (required parameter).

[0210] The heterogeneous core verification steps are as follows:

[0211] Step 1: Complete the above JSON configuration file based on the SOC chip architecture and hardware specifications.

[0212] Step 2: Use a script to generate a unified SOC verification platform (usvp) based on the JSON configuration file.

[0213] 1. Use Python to parse the JSON script and extract relevant parameter information, such as the number of cores, core architecture, RAM base address, etc.

[0214] 2. Based on Jinja2 (a template engine) template technology, the directory structure of the unified SOC verification platform is templated;

[0215] 3. Then, through template rendering, the JSON configuration information is filled into the template and a complete unified SOC verification platform is generated.

[0216] Step 3: Modify the include_ directory in the top directory <subsys>The _test_top.sv file mainly modifies the connection between the AMBA bus interface of cpu_monitor and the AMBA bus interface of CORE for printing monitoring; this file mainly contains code specific to different Subsys, such as CPU monitor code instantiation, backdoor loading instruction hex file method, etc.

[0217] Step 4: After completing the above modifications, the user can execute the script to generate a verification environment with hello_world ("Hello World" program) test cases that come with each CORE subsystem. The user generates these test cases using the script template, and after simulation, the string "Hello World" will be printed on the screen.

[0218] Step 5: After the basic test cases are tested and working, users can add test cases themselves for verification.

[0219] Heterogeneous core individual verification steps:

[0220] 1. In the bin / case_cfg directory <subsys>In the _case.cfg file, refer to the generated example to fill in the test case configuration, including some hardware compilation and simulation options, as well as Makefile instructions for software compilation.

[0221] 2. If it is an interface-type IP verification, the VIP to be connected needs to be instantiated in the env directory (this step can be skipped for non-interface-type IPs).

[0222] 3. In tests / <subsys>The test cases in the directory are constructed with reference to hello_world, and are divided into SV part and CCode part.

[0223] 4. Include the written test case SV part into tests / include_ <subsys>Simulation verification can then be performed in _test.svi.

[0224] Heterogeneous core collaborative verification steps:

[0225] 1. Write test case configurations in files such as bin. Note that the hardware compilation parameters need to include two macros at the same time. Secondly, the software compilation Makefile instructions need to include both the apcpu (application processor) and sp (sub-processor) Makefile instructions.

[0226] 2. Complete the test case construction for the apcpu part in the tests / apcpu directory and the test case construction for the sp part in the tests / sp directory. The two heterogeneous cores can be synchronized by sharing memory.

[0227] 3. Simply execute the test cases for simulation and debugging.

[0228] In the above embodiments, when verifying heterogeneous cores, by using a configuration file containing at least the heterogeneous core parameters of the heterogeneous cores in the chip to be analyzed as a single data source, a directory file for a verification platform to be generated corresponding to the chip to be analyzed can be specifically generated. This allows for the automatic generation of a verification platform that matches the chip to be analyzed, and then unified verification of the heterogeneous cores in the chip to be analyzed can be performed based on this verification platform, which is beneficial to improving the convenience of heterogeneous core verification. Moreover, it avoids the shortcomings of traditional technologies that use verification platforms built on the subsystems of each heterogeneous core, which easily leads to a lack of more realistic full-chip scenario verification and thus results in low convenience of heterogeneous core verification, further improving the convenience of heterogeneous core verification.

[0229] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0230] Based on the same inventive concept, this application also provides a heterogeneous core verification apparatus for implementing the heterogeneous core verification method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more embodiments of the heterogeneous core verification apparatus provided below can be found in the limitations of the heterogeneous core verification method described above, and will not be repeated here.

[0231] In one exemplary embodiment, such as Figure 8 As shown, a heterogeneous kernel verification device is provided, including: a file acquisition module 801, a file generation module 802, a platform generation module 803, and a heterogeneous kernel verification module 804, wherein:

[0232] The file acquisition module 801 is used to acquire the configuration file corresponding to the chip to be analyzed; the configuration file includes at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed.

[0233] The file generation module 802 is used to generate a directory file of the verification platform corresponding to the chip to be analyzed, based on the configuration file.

[0234] The platform generation module 803 is used to generate the verification platform corresponding to the chip to be analyzed based on the directory file.

[0235] The heterogeneous core verification module 804 is used to verify the heterogeneous cores in the chip to be analyzed through the verification platform and obtain the verification results of the heterogeneous cores.

[0236] In an exemplary embodiment, the file generation module 802 is further configured to parse the configuration file to obtain the configuration parameters corresponding to the chip to be analyzed; the configuration parameters include at least heterogeneous core parameters; obtain the directory file template of the verification platform to be generated corresponding to the chip to be analyzed, add the configuration parameters to the corresponding position in the directory file template, and obtain the directory file of the verification platform to be generated corresponding to the chip to be analyzed.

[0237] In an exemplary embodiment, the heterogeneous core verification device further includes a parameter verification module, which is used to extract the mandatory configuration parameters from the configuration parameters; perform non-empty verification processing on the mandatory configuration parameters to obtain the verification result; and a file generation module 802 is used to add the configuration parameters to the corresponding position in the directory file template when the verification result indicates that the mandatory configuration parameters are non-empty, so as to obtain the directory file of the verification platform to be generated corresponding to the chip to be analyzed.

[0238] In an exemplary embodiment, the platform generation module 803 is further configured to modify the directory file according to the configuration file to obtain a modified directory file; and generate a verification platform corresponding to the chip to be analyzed according to the modified directory file.

[0239] In an exemplary embodiment, the heterogeneous core verification device further includes a use case simulation module, which is used to obtain the basic use cases corresponding to the heterogeneous cores in the chip to be analyzed from the directory file; execute the basic use cases in the verification platform to obtain the simulation results corresponding to the basic use cases; the heterogeneous core verification module 804 is also used to verify the heterogeneous cores in the chip to be analyzed through the verification platform when the simulation results corresponding to the basic use cases indicate that the basic use case simulation has passed, and obtain the verification results of the heterogeneous cores.

[0240] In an exemplary embodiment, the heterogeneous core verification module 804 is further configured to, when the simulation result corresponding to the basic use case indicates that the basic use case simulation has passed, configure the use case parameters corresponding to the heterogeneous core according to the verification method corresponding to the heterogeneous core; generate the target use case corresponding to the heterogeneous core according to the use case parameters; execute the target use case in the verification platform to obtain the simulation result of the target use case; and obtain the verification result of the heterogeneous core based on the simulation result of the target use case.

[0241] Each module in the aforementioned heterogeneous core verification device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0242] In one exemplary embodiment, a terminal is provided, the internal structure of which can be as follows: Figure 9 As shown, the computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a heterogeneous core verification method.

[0243] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0244] This embodiment also provides a base station, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the heterogeneous core verification method described above.

[0245] This embodiment also provides a chip, which includes at least one processor. When the processor executes a computer program, it implements the steps of the heterogeneous core verification method described above.

[0246] This embodiment also provides a chip module coupled to a memory, which is used to implement the steps of the heterogeneous core verification method described above when executing a computer program stored in the memory.

[0247] This embodiment also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the heterogeneous core verification method described above.

[0248] This embodiment also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the heterogeneous core verification method described above.

[0249] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to mutually. In addition, different parts between embodiments can also be combined with each other, and this invention does not limit this.

[0250] The heterogeneous core verification method, apparatus, terminal, base station, chip, chip module, computer-readable storage medium, and computer program product provided in this embodiment obtain a configuration file corresponding to the chip to be analyzed. The configuration file includes at least the heterogeneous core parameters of the heterogeneous cores in the chip to be analyzed. Based on the configuration file, a directory file for a verification platform to be generated corresponding to the chip to be analyzed is generated. Based on the directory file, a verification platform corresponding to the chip to be analyzed is generated. Through the verification platform, the heterogeneous cores in the chip to be analyzed are verified to obtain the verification results of the heterogeneous cores. When verifying heterogeneous cores, by using the configuration file, which includes at least the heterogeneous core parameters of the heterogeneous cores in the chip to be analyzed, as a single data source, a directory file for a verification platform to be generated corresponding to the chip to be analyzed can be generated specifically. This allows for the automatic generation of a verification platform that matches the chip to be analyzed. Furthermore, based on this verification platform, a unified verification of the heterogeneous cores in the chip to be analyzed can be performed, which improves the convenience of heterogeneous core verification. Moreover, it avoids the shortcomings of traditional technologies that use verification platforms built in the subsystems of each heterogeneous core, which easily leads to a lack of more realistic full-chip scenario verification and thus results in low convenience of heterogeneous core verification. This further improves the convenience of heterogeneous core verification.

[0251] Regarding the modules / units included in the various devices and products described in the above embodiments, they can be software modules / units, hardware modules / units, or a combination of both. For example, for various devices and products applied to or integrated into a chip, all of their modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits; for various devices and products applied to or integrated into a chip module, all of their modules / units can be implemented using hardware methods such as circuits, and different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The components can be implemented using software programs that run on the processor integrated within the chip module. The remaining (if any) modules / units can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into the terminal, each of its components / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or in different components within the terminal. Alternatively, at least some modules / units can be implemented using software programs that run on the processor integrated within the terminal, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits.

[0252] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0253] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0254] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.< / subsys> < / subsys> < / subsys> < / subsys> < / subsys> < / subsys>

Claims

1. A heterogeneous kernel verification method, characterized in that, The method includes: Obtain the configuration file corresponding to the chip to be analyzed; the configuration file includes at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed; Based on the configuration file, generate the directory file of the verification platform to be generated corresponding to the chip to be analyzed; Based on the directory file, a verification platform corresponding to the chip to be analyzed is generated; The heterogeneous core in the chip to be analyzed is verified using the verification platform, and the verification result of the heterogeneous core is obtained.

2. The method according to claim 1, characterized in that, The step of generating a directory file for the verification platform corresponding to the chip to be analyzed, based on the configuration file, includes: The configuration file is parsed to obtain the configuration parameters corresponding to the chip to be analyzed; the configuration parameters include at least the heterogeneous core parameters; Obtain the directory file template of the verification platform to be generated corresponding to the chip to be analyzed, and add the configuration parameters to the corresponding position in the directory file template to obtain the directory file of the verification platform to be generated corresponding to the chip to be analyzed.

3. The method according to claim 2, characterized in that, Before adding the configuration parameters to the corresponding positions in the directory file template to obtain the directory file of the verification platform to be generated corresponding to the chip to be analyzed, the method further includes: Extract the required configuration parameters from the configuration parameters; The required configuration parameters are subjected to non-empty validation to obtain the validation result; The step of adding the configuration parameters to the corresponding position in the directory file template to obtain the directory file of the verification platform to be generated for the chip to be analyzed includes: If the verification result indicates that the required configuration parameter is not empty, the configuration parameter is added to the corresponding position in the directory file template to obtain the directory file of the verification platform to be generated corresponding to the chip to be analyzed.

4. The method according to claim 1, characterized in that, The step of generating the verification platform corresponding to the chip to be analyzed based on the directory file includes: Based on the configuration file, the directory file is modified to obtain the modified directory file; Based on the modified directory file, a verification platform corresponding to the chip to be analyzed is generated.

5. The method according to any one of claims 1 to 4, characterized in that, Before verifying the heterogeneous core in the chip to be analyzed through the verification platform and obtaining the verification result of the heterogeneous core, the process further includes: From the directory file, obtain the basic use cases corresponding to the heterogeneous cores in the chip to be analyzed; The basic test case is executed in the verification platform to obtain the simulation results corresponding to the basic test case. The process of verifying the heterogeneous cores in the chip to be analyzed through the verification platform to obtain the verification results of the heterogeneous cores includes: If the simulation results corresponding to the basic use case indicate that the simulation of the basic use case is successful, the heterogeneous core in the chip to be analyzed is verified through the verification platform to obtain the verification result of the heterogeneous core.

6. The method according to claim 5, characterized in that, When the simulation result corresponding to the basic use case indicates that the basic use case simulation has passed, the heterogeneous core in the chip to be analyzed is verified through the verification platform to obtain the verification result of the heterogeneous core, including: If the simulation result corresponding to the basic use case indicates that the basic use case simulation is successful, configure the use case parameters corresponding to the heterogeneous core according to the verification method corresponding to the heterogeneous core. Based on the use case parameters, generate the target use case corresponding to the heterogeneous core; The target use case is executed in the verification platform to obtain the simulation results of the target use case; Based on the simulation results of the target use case, the verification results of the heterogeneous core are obtained.

7. A heterogeneous core verification device, characterized in that, The device includes: The file acquisition module is used to acquire the configuration file corresponding to the chip to be analyzed; the configuration file includes at least the heterogeneous core parameters of the heterogeneous core in the chip to be analyzed; The file generation module is used to generate a directory file of the verification platform corresponding to the chip to be analyzed, based on the configuration file. The platform generation module is used to generate a verification platform corresponding to the chip to be analyzed based on the directory file. The heterogeneous core verification module is used to verify the heterogeneous core in the chip to be analyzed through the verification platform, and obtain the verification result of the heterogeneous core.

8. A terminal comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A base station, comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

10. A chip, characterized in that, The chip includes at least one processor, which executes a computer program to implement the steps of the method according to any one of claims 1 to 6.

Images