Chip test configuration file generation method, device, equipment, medium and program

Abstract

Embodiments of the present application disclose a chip test configuration file generation method, device, equipment, medium and program, wherein the method comprises: collecting real-time state association information of each test stage of a chip test general pipeline in a chip test process; and generating a standardized chip test configuration file according to the real-time state association information. The technical scheme of the embodiments of the present application can improve the completeness, accuracy and standardization degree of the configuration information in the chip test configuration file, and is conducive to realizing the standardized expression and accurate reproduction of the chip test scene.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of chip and testing technology, and in particular to a method, apparatus, electronic device, storage medium and program for generating chip test configuration files. Background Technology

[0002] Due to the inherent complexity of chip companies' software stacks, their testing pipelines also exhibit correspondingly higher complexity.

[0003] Currently, when testing chips, whether ordinary chips or AI (Artificial Intelligence) chips, the industry generally adopts CI (Continuous Integration) / CD (Continuous Delivery) pipelines for automated testing. This CI / CD pipeline automated testing method uses common configuration files, such as JSON (JavaScript Object Notation) or YAML (YAML Ain't Markup Language, a lightweight and data-centric serialization language), to define the test process and configure parameters.

[0004] However, the existing chip software test configuration description methods have the following problems: (1) Lack of domain-specific structural abstraction of chip test scenarios: The general configuration files used in the existing chip test process only provide data serialization capabilities, do not have field constraints in the chip test domain, and cannot express chip-specific concepts such as accelerator card operation mode (e.g., physical / virtual / segmentation), firmware version constraints, and power consumption mode. They also lack a structured expression of the multi-layer dependency relationship between hardware-software-dependency-execution. (2) Incomplete description of the test environment: Traditional test scripts lack the ability to accurately describe the hardware environment. Key information such as driver installation parameters and runtime configurations are scattered in multiple places, making it impossible to form a complete environment snapshot for problem reproduction. (3) Non-self-descriptive nature of configuration information: The general configuration files used in the existing chip test process lack a data mode version control mechanism. The configuration information cannot explain its meaning and purpose. The configuration formats are not uniform between different projects, making it difficult to achieve standardization. Summary of the Invention

[0005] This invention provides a method, apparatus, electronic device, storage medium, and program for generating chip test configuration files, which can improve the completeness, accuracy, and standardization of configuration information in chip test configuration files, and facilitate the standardized expression and accurate reproduction of chip test scenarios.

[0006] According to one aspect of the present invention, a method for generating a chip test configuration file is provided, comprising:

[0007] Collect real-time status correlation information of each test stage in the chip testing process of a general chip testing pipeline;

[0008] A standardized chip test configuration file is generated based on the real-time status association information.

[0009] According to another aspect of the present invention, a chip test configuration file generation apparatus is provided, comprising:

[0010] The real-time status association information acquisition module is used to collect real-time status association information of the chip testing pipeline at each testing stage during chip testing.

[0011] The chip test configuration file generation module is used to generate a standardized chip test configuration file based on the real-time status association information.

[0012] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0013] At least one processor; and a memory communicatively connected to said at least one processor; wherein,

[0014] The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to execute the chip test configuration file generation method according to any embodiment of the present invention.

[0015] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the chip test configuration file generation method according to any embodiment of the present invention.

[0016] According to another aspect of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a processor, implements the chip test configuration file generation method described in any embodiment of the present invention.

[0017] This invention collects real-time status correlation information of a general chip testing pipeline during each testing stage of the chip testing process, and generates a standardized chip test configuration file based on the collected real-time status correlation information. This solves the problem that the general configuration file in the existing chip testing scenario cannot meet the chip-specific testing requirements, and can improve the completeness, accuracy and standardization of the configuration information in the chip test configuration file, which is conducive to the standardized expression and accurate reproduction of chip testing scenarios.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

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

[0020] Figure 1 This is a flowchart of a chip test configuration file generation method provided in Embodiment 1 of the present invention;

[0021] Figure 2 This is a flowchart of a chip test configuration file generation method provided in Embodiment 2 of the present invention;

[0022] Figure 3 This is a schematic diagram of the architecture of a chip test configuration file generation system provided in an embodiment of the present invention;

[0023] Figure 4 This is a schematic diagram of the data structure of a chip test configuration file provided in an embodiment of the present invention;

[0024] Figure 5 This is a schematic diagram of a chip test configuration file generation device provided in Embodiment 3 of the present invention;

[0025] Figure 6 This is a schematic diagram of the structure of an electronic device provided in Embodiment 4 of the present invention. Detailed Implementation

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

[0027] It should be noted that the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product or device.

[0028] Example 1

[0029] Figure 1 This is a flowchart of a chip test configuration file generation method provided in Embodiment 1 of the present invention. This embodiment is applicable to situations where a chip-specific test configuration file is generated based on real-time status correlation information collected during chip testing. This method can be executed by a chip test configuration file generation device, which can be implemented in software and / or hardware, and is generally integrated into an electronic device. This electronic device can be a terminal device or a server device, as long as it can execute the chip test configuration file generation method. The present invention does not limit the specific type of electronic device. Correspondingly, as... Figure 1 As shown, the method includes the following operations:

[0030] S110: Collect real-time status association information of each test stage in the chip testing process of the general chip testing pipeline.

[0031] The general-purpose chip testing pipeline can be any common pipeline currently used for chip testing, such as a chip CI / CD pipeline. This embodiment of the invention does not limit the type of general-purpose chip testing pipeline or the testing process. Real-time status association information can be multi-dimensional status information collected in real-time at each testing stage of the general-purpose chip testing pipeline.

[0032] S120. Generate a standardized chip test configuration file based on the real-time status association information.

[0033] The chip test configuration file can be a configuration file specifically designed for testing the chip. Optionally, the chip for which the chip test configuration file needs to be generated can be an AI chip or a regular chip; this embodiment of the invention does not limit the type of chip to which the chip test configuration file is adapted.

[0034] In this embodiment of the invention, a configuration instance generation tool can be used to automatically generate chip-specific test configuration files based on information collected from a general chip testing pipeline. The configuration instance generation tool can include a state capture module and a configuration file generation module. The state capture module and the configuration file generation module maintain a communication connection. The state capture module is responsible for collecting state information from each relevant test stage of the general chip testing pipeline during chip testing, and integrating the collected state information from each test stage to obtain real-time state association information. For example, the state capture module can collect state information in real-time at each stage of the CI / CD pipeline, including environment preparation, driver installation, software configuration, and test execution. The state capture module can store the collected real-time state association information in an internal data structure, such as a StateCollector object, and pass it to the configuration file generation module after pipeline execution is complete. Further, after pipeline execution is complete, the state capture module sends the real-time state association information to the configuration file generation module. The configuration file generation module can parse and integrate the real-time state association information sent by the state capture module to generate the final standardized chip test configuration file.

[0035] Since a typical chip testing pipeline may include multiple testing stages, and the status information collected in each stage may include multiple types, the status capture module can classify the real-time status-related information according to chip testing requirements. Correspondingly, the configuration file generation module can extract key information from each type of real-time status-related information and organize this extracted key information according to standard requirements to generate a structured configuration file, thus obtaining a standardized chip test configuration file. Compared to traditional methods that require manual configuration file writing, which is prone to missing key information or inconsistencies, the configuration instance generation tool, through the cooperation of the status capture module and the configuration file generation module, achieves automatic conversion from pipeline execution to configuration file generation, ensuring the completeness, accuracy, and consistency of configuration information.

[0036] This invention collects real-time status correlation information of a general chip testing pipeline during each testing stage of the chip testing process, and generates a standardized chip test configuration file based on the collected real-time status correlation information. This solves the problem that the general configuration file in the existing chip testing scenario cannot meet the chip-specific testing requirements, and can improve the completeness, accuracy and standardization of the configuration information in the chip test configuration file, which is conducive to the standardized expression and accurate reproduction of chip testing scenarios.

[0037] Example 2

[0038] Figure 2This is a flowchart of a chip test configuration file generation method provided in Embodiment 2 of the present invention. This embodiment is based on the above embodiment and is further specified. In this embodiment, various specific optional implementation methods for collecting real-time status correlation information and generating standardized chip test configuration files are given. Correspondingly, as... Figure 2 As shown, the method in this embodiment may include:

[0039] S210. During the environmental preparation phase of the general pipeline for chip testing, collect hardware information of the chip equipment.

[0040] Among them, the environment preparation stage of the general pipeline for chip testing is the fundamental link to ensure high accuracy and high reliability of the testing process. It mainly includes the comprehensive readiness preparation of the testing environment, equipment, samples and solutions.

[0041] Optionally, the status capture module can include various types of data collectors, such as hardware information collectors, software version recorders, environment variable snapshotters, and command execution recorders. Hardware information collectors can collect chip hardware information, such as GCU (General Computing Unit) device ID, quantity, and operating mode. Software version recorders can record information such as driver versions, runtime versions, and container image versions. Environment variable snapshotters can capture key environment variables within the host machine and containers. Command execution recorders can record the command sequences executed at each stage, such as the chip detection command: target_check_cmd, and the driver installation command: kmd_install_cmd.

[0042] Specifically, the hardware information collector can collect chip device hardware information during the environment preparation phase of a general-purpose chip testing pipeline, such as detecting GCU device IDs and quantities using the lspci (List PCI devices) command. Optionally, during the environment preparation phase, the status capture module can also capture host environment variables using an environment variable snapshotter and record system check commands such as system_check_cmd and chip detection commands such as target_check_cmd using a command execution recorder.

[0043] S220. During the driver installation phase of the general pipeline for chip testing, collect chip software version association information.

[0044] The driver installation phase of the general-purpose chip testing pipeline is a crucial step in ensuring stable communication between automated test equipment and the host system. This phase primarily involves the correct deployment of debugger / programmer drivers, USB (Universal Serial Bus) to serial port drivers, and chip manufacturer-specific drivers. Chip software version association information can be information associated with the chip's software version, such as, but not limited to, driver version number, driver installation commands, and driver parameters.

[0045] Accordingly, the status capture module can collect and store chip software version-related information during the driver installation phase of the chip testing pipeline using a software version recorder and a command execution recorder. For example, the status capture module can record driver version information using the software version recorder and record driver installation commands such as kmd_install_cmd and the driver installation parameters included in those commands using the command execution recorder.

[0046] S230. During the software configuration phase of the chip testing pipeline, collect snapshot information of environmental variables.

[0047] The software configuration phase of the general chip testing pipeline mainly involves the initialization and parameterization of test programs, test environments, automated scripts, and toolchains. The purpose is to ensure that the test process can efficiently and accurately perform chip function and performance verification.

[0048] Correspondingly, the status capture module can collect environment variable snapshot information of the storage chip during the software configuration phase of the chip testing pipeline using a software version recorder and a command execution recorder. Optionally, the environment variable snapshot information may include, but is not limited to, container image version, container startup parameters, SDK (Software Development Kit) version, and environment variable setting commands. For example, the status capture module can record information such as the chip's container image version and SDK version using the software version recorder, and record container startup commands such as docker_launch_cmd and container environment setting commands using the command execution recorder. For example, when installing via the SDK, the container environment setting command could be container_env_setup.

[0049] S240. During the test execution phase of the general pipeline for chip testing, collect test command execution record information.

[0050] The test execution phase of a general chip testing pipeline mainly includes wafer testing, packaging testing, and system-level testing to verify the chip's functionality, performance, and reliability. Test command execution log information may include, but is not limited to, test command sequences and core dump file paths, as well as other information related to the execution of test commands.

[0051] Accordingly, the status capture module can record and store various test command information of the chip during the test execution phase of the general-purpose chip test pipeline using a command execution recorder. For example, the status capture module can record and store test command prefixes and test command sequences consisting of various types of test commands using the command execution recorder. If the chip crashes during the test execution phase of the general-purpose chip test pipeline, it can also record the core dump file path for crash analysis. The core dump file path refers to the specified location on disk where the test state is saved when the test process terminates abnormally.

[0052] It can be seen that the status capture module collaborates with various data acquisition devices at each stage of the general chip testing pipeline to collect all the status information required by the chip test configuration file.

[0053] S250. Fill the preset data structure of the chip test configuration file according to the real-time status association information to obtain the initial chip test configuration file.

[0054] The preset data structure can be a dedicated data structure specifically configured for the chip test configuration file, taking into account the chip's characteristics. The initial chip test configuration file can be a chip test configuration file initially generated based on real-time status association information and the preset data structure of the chip test configuration file.

[0055] In this embodiment of the invention, the configuration file generation module receives full state information collected by the state capture module, and generates a standardized chip test configuration file through the collaborative efforts of three components: a template filling engine, a pattern validator, and a file serializer. Correspondingly, the configuration file generation module can use the template filling engine to fill the received real-time state association information into a preset data structure of the chip test configuration file to obtain an initial chip test configuration file.

[0056] In an optional embodiment of the present invention, the step of filling the preset data structure of the chip test configuration file according to the real-time status association information may include: extracting metadata fields from the real-time status association information and filling the metadata area structure of the chip test configuration file according to the metadata fields; extracting chip hardware environment detection fields from the real-time status association information and filling the hardware environment description area structure of the chip test configuration file according to the chip hardware environment detection fields; extracting chip software environment fields from the real-time status association information and filling the software environment description area structure of the chip test configuration file according to the chip software environment fields; extracting environment configuration fields from the real-time status association information and filling the environment configuration area structure of the chip test configuration file according to the environment configuration fields; and extracting test execution fields from the real-time status association information and filling the test execution description area structure of the chip test configuration file according to the test execution fields.

[0057] Metadata, in this context, refers to data that describes data. It doesn't contain the data itself, but rather provides key information about the data's structure, meaning, source, and purpose, helping people and systems understand, manage, discover, and use the data. Metadata fields can be related fields that describe metadata. The metadata area structure (or metadata area for short) can be a data structure within a pre-defined data structure used for version control and traceability management of configuration files. Chip hardware environment detection data mainly refers to real-time monitoring parameters of the chip's physical environment and its own operating status during chip operation or testing, used to ensure stability, reliability, and security. This data is typically collected by on-chip sensors or external monitoring systems, covering multiple dimensions such as temperature, voltage, power consumption, humidity, and vibration. Chip hardware environment detection fields can be related fields that describe chip hardware environment detection data. The hardware environment description area structure (or hardware environment description area for short) can be a data structure within a pre-defined data structure specifically used to describe the chip hardware detection logic. Chip software environment data refers to configuration, status, and behavioral information closely related to the chip's software system during chip operation, testing, or development, used to ensure normal collaboration between software and hardware, and to support functional verification, performance tuning, and fault diagnosis. Chip software environment fields can be fields that describe data related to the chip software environment. The software environment description area structure (or simply software environment description area) can be a data structure used to describe chip drivers, runtime libraries, and container environments. Environment configuration data is a set of key parameters that ensures the chip can work stably during development, testing, and operation. It covers hardware, software, and physical environment settings and directly affects system compatibility, performance, and reliability. Environment configuration fields can be fields that describe environment configuration data. The environment configuration area structure (or simply environment configuration area) can be a data structure used to describe the environment settings within the host machine and containers. Test execution data consists of all raw records and results generated by the software or hardware during testing. It is used to evaluate system functionality, performance, and stability and is the core basis for quality assurance and problem tracing. Test execution fields can be fields that describe test execution data. The test execution description area structure (or simply test execution description area) can be a data structure used to describe test commands and result data.

[0058] Optionally, the preset data structure can be organized according to the five-zone structure configured in the chip test configuration specification. The template filling engine can perform data filling operations on the real-time status association information according to the five-zone data structure configured in the chip test configuration specification. Specifically, the template filling engine can extract metadata fields from the real-time status association information and fill the metadata zone structure of the chip test configuration file according to the metadata fields. For example, metadata fields can include, but are not limited to, version (version number), jobid (workspace ID), repo (configuration item), job_url (workspace link), and cdash_url. Among them, the version field is used to record the version number of the configuration specification for backward compatibility management, and is identified by the version number when the specification is upgraded; the jobid field is a unique identifier for the test task, supports variable substitution, and is used to distinguish different test tasks; the repo field is the associated code repository address, used to trace the source code version corresponding to the test scenario; the job_url field is the URL (Uniform Resource Locator) of the associated chip test general pipeline task, used to trace the generation source of the chip test configuration file; the cdash_url field is the test result dashboard URL, used to view test execution results and history.

[0059] Specifically, the template filling engine can also extract chip hardware environment detection fields from real-time status association information and fill the hardware environment description area structure of the chip test configuration file based on these fields. The description data in the hardware environment description area structure are core differentiating fields from general test configuration files, reflecting the specificity of chip testing. For example, chip hardware environment detection fields may include, but are not limited to, the `target_check_cmd` field and the `system_check_cmd` field. The `target_check_cmd` field may include a list of chip detection commands used to verify the existence and status of the target chip (such as a target AI accelerator card or general-purpose chip). For example, the `lspci` command can be used to detect the vendor ID and device ID of the GCU device. The `system_check_cmd` field may include a list of system environment check commands used to verify whether system-level dependencies such as operating system mount points and kernel versions meet the requirements.

[0060] Specifically, the template filling engine can also extract chip software environment fields from real-time status association information and fill the software environment description area structure of the chip test configuration file according to the chip software environment fields. For example, chip software environment fields may include, but are not limited to, fields such as image (container image), container (container example), package_url (package URL), kmd_install_cmd (driver installation command), docker_launch_cmd (container startup command), container_env_prefix (adding a uniform prefix to environment variables injected into the container from external resources), and download_cmds (package download commands). The `image` field can include the complete address of the container image (including the repository path and version tag); the `container` field can include the container instance name, supporting variable substitution to achieve multi-scenario isolation; the `package_url` field can include the download address of software packages (such as SDKs and toolchains); the `kmd_install_cmd` field can include the installation command for the Kernel Mode Driver (KMD), which includes driver installation parameters such as `--driver -y --no-auto-load`; the `docker_launch_cmd` field can include a list of container startup commands, which include parameters such as mount paths and device mappings; the `container_env_prefix` field can include a prefix for command execution within the container, such as `docker exec -it {container}`, used for concatenating subsequent commands; and the `download_cmds` field can include a sequence of software package download commands, which can be executed sequentially to obtain the required files.

[0061] Specifically, the template filling engine can also extract environment configuration fields from real-time status association information and fill the environment configuration area structure of the chip test configuration file according to the environment configuration fields. For example, environment configuration fields may include, but are not limited to, the host_env_setup (host machine environment settings) field, the container_env_setup (container in-container environment settings) field, and the test_env_type (test environment type identifier) ​​field. The host_env_setup field may include a list of host machine environment setting commands, such as setting environment variables and creating directories; the container_env_setup field may include a list of container in-container environment setting commands, such as installing SDKs and configuring library paths; the test_env_type field may include a test environment type identifier, such as dev (development), CI (Continuous Integration), and prod (production), used to distinguish configuration strategies for different environments.

[0062] Specifically, the template filling engine can also extract test execution fields from real-time status association information and fill the test execution description area structure of the chip test configuration file according to the test execution fields. For example, test execution fields may include, but are not limited to, fields such as test_prefix (test command prefix), tests (test command sequence), and corefile (core dump file path). The test_prefix field can include a common prefix for test commands, such as changing directories or activating environments; the tests field can include a sequence of test commands, which can be executed sequentially; the corefile field can include the path to the core dump file, used for debugging and analysis of crash issues.

[0063] Once the five-zone structure of the preset data structure is filled in, an initial chip test configuration file in dict (a dictionary data structure, essentially a collection of key-value pairs) structure format can be generated.

[0064] The five-zone structure of the aforementioned pre-defined data structure intuitively reflects the dependency hierarchy of the chip testing environment: metadata → hardware → software → environment → execution. Each layer has a clear responsibility, facilitating automated parsing. Fields such as `target_check_cmd` and `kmd_install_cmd` in the chip test configuration file are specialized abstractions for AI chip testing scenarios, filling the gaps in general configuration formats. Simultaneously, the chip test configuration file supports an automatic variable replacement mechanism for placeholders such as `{user}` and `{version}`, enabling chip configuration templates and reuse. All execution-related fields in the chip test configuration file are list types, clearly defining the command execution order and dependencies.

[0065] S260. Standardize and verify the configuration data in the initial chip test configuration file.

[0066] To further ensure the usability and accuracy of the chip test configuration file, after generating the initial chip test configuration file, the configuration data in the initial chip test configuration file can be further standardized and verified to verify whether the configuration data in the initial chip test configuration file conforms to the chip test configuration specifications.

[0067] In an optional embodiment of the present invention, the standardization verification of the configuration data in the initial chip test configuration file may include: verifying the completeness of the required fields in the initial chip test configuration file; verifying the correctness of the field types in the initial chip test configuration file; verifying the validity of the chip-specific fields in the initial chip test configuration file; and verifying the coverage of the necessary fields for the test scenario in the initial chip test configuration file.

[0068] Specifically, the configuration file generation module can use a pattern validator to standardize and validate the configuration data in the initial chip test configuration file, checking field completeness and data types. The pattern validator can verify the completeness of required fields in the initial chip test configuration file. Optionally, required fields may include, but are not limited to, `meta.version` (metadata structure version), `meta.jobid` (the workspace to which the metadata belongs), and `software.image` (a field recording the container image containing the runtime library). Simultaneously, the pattern validator can verify the correctness of field types in the initial chip test configuration file. For example, it needs to verify that the `tests` field type must be `list`, and the `kmd_install_cmd` field type must be `string`. The pattern validator can also verify the validity of chip-specific fields in the initial chip test configuration file, such as verifying whether the `target_check_cmd` field contains AI chip detection commands. Finally, the pattern validator can also verify the coverage of necessary fields for test scenarios in the initial chip test configuration file. Optionally, test scenarios may include, but are not limited to, core dump scenarios, device test scenarios, and library API (Application Programming Interface) test scenarios. Correspondingly, necessary fields for test scenarios can be fields that must be configured for the aforementioned test scenarios.

[0069] Accordingly, if the initial chip test configuration file passes verification, the subsequent process can continue; if the initial chip test configuration file fails verification, an error report can be automatically generated based on the errors detected during the verification process.

[0070] S270. If the initial chip test configuration file is verified, the initial chip test configuration file is serialized to obtain the standardized chip test configuration file.

[0071] If the initial chip test configuration file passes verification, the configuration file generation module can further serialize it using a file serializer, such as serializing the configuration data into JSON and / or YAML format. In an optional embodiment of the invention, during the serialization process of the file serializer, the initial chip test configuration file can be formatted and indented according to a set standard format to improve readability; a configuration file generation timestamp and generation system identifier can also be added to the initial chip test configuration file. After serializing the initial chip test configuration file, the file serializer can output a standardized and highly readable self-describing configuration file, thereby obtaining a standardized chip test configuration file.

[0072] Optionally, the generated standardized chip test configuration file, as an output of the general chip testing pipeline, can be archived in the artifact repository. It can also be associated with test tasks in the general chip testing pipeline via fields such as job_url to test the target chip, or it can be provided to supporting devices for rapid reproduction of the chip testing environment. This embodiment of the invention does not limit the specific application scenarios of the standardized chip test configuration file.

[0073] In an optional embodiment of the present invention, the standardized chip test configuration file covers at least one of the following test scenarios: core dump analysis scenario, temporary file and working directory scenario, device test environment scenario, and library API test scenario. That is, the standardized chip test configuration file, through its five-zone structure, can comprehensively cover various key test scenarios for chip testing.

[0074] Optionally, to cover core dump analysis scenarios, the chip test configuration file can record the complete path of the core dump file, such as " / path / to / core.12345", through the `execution.corefile` field (a field related to query execution that can be used to store the physical file containing intermediate results); it can also record the test commands that triggered the crash through the `execution.tests` field (a field used to record test commands), and record the debug symbol installation commands, such as `apt-get install gdb` (a command used to install GDB), through the `environment.container_env_setup` field (a field used to initialize or set container environment variables). When the chip test configuration file is provided to the supporting device to reproduce the test scenario, the supporting device can automatically download the core dump file, rebuild the crash environment, and start gdb (GNU Debugger, a powerful program debugging tool developed by the GNU project) for stack analysis based on the above fields.

[0075] Optionally, to cover temporary file and working directory scenarios, the chip test configuration file can configure the working directory name through the `meta.jobid` field (a workspace field in metadata) to achieve mutual isolation between test scenarios. The chip test configuration file can also record temporary file download commands through the `software.download_cmds` field (a field specifying the list of commands to be executed for downloading software) and temporary directory creation commands through the `environment.host_env_setup` field (a field for setting and configuring environment variables in the host environment). When the chip test configuration file is provided to the supporting device to reproduce the test scenario, the supporting device can create an independent working directory corresponding to the current test scenario based on the `jobid`, download the required temporary files, and avoid conflicts between multiple scenarios.

[0076] Optionally, to cover device testing environment scenarios, the chip test configuration file can record chip (such as AI accelerator card) detection commands via the `hardware.target_check_cmd` field (a field used to define a command or script for checking the status or performance of a hardware target), such as `lspci -d 1e36`: detects the GCU device. The chip test configuration file can also record device node check commands via the `hardware.system_check_cmd` field (a field used to define a command or script for checking the status or performance of a hardware system), and driver installation commands and parameters via the `software.kmd_install_cmd` field (a field storing kernel driver mode information). When the chip test configuration file is provided to the supporting device to reproduce the test scenario, the supporting device can verify the chip's existence, check device nodes, and install the correct driver version based on the above fields, ensuring device usability.

[0077] Optionally, to cover library API testing scenarios, the chip test configuration file can record the container image containing the runtime library through the `software.image` field (a software image type field), the SDK installation commands through the `environment.container_env_setup` field (a field used to control the initialization settings of the container environment), the library path settings through the `environment.host_env_setup` field, and the API test commands through the `execution.tests` field. When the chip test configuration file is provided to the supporting device to reproduce the test scenario, the supporting device can start the correct version of the container, install the SDK, configure the library path, and execute API tests according to the above fields, thus fully reproducing the library API testing environment.

[0078] Therefore, the five-zone structure of the chip test configuration file ensures the integrity of the chip test scenario. The configuration information in the metadata zone can provide scenario identification and traceability; the configuration information in the hardware environment description zone can ensure that hardware dependencies are verifiable; the configuration information in the software environment description zone can ensure that the software version is reproducible; the configuration information in the environment configuration zone can ensure that environment variables and settings are recoverable; and the configuration information in the test execution description zone can ensure that test cases can be re-executed.

[0079] The above technical solution addresses the problem that existing general-purpose testing pipelines lack standardized configuration description languages ​​specifically for chip testing scenarios, making it difficult to accurately describe and reproduce chip testing environments. It provides a method for generating domain-specific test configuration files to describe chip testing scenarios. This method uses a hierarchical partitioning structure to fill and organize the real-time status association information of each testing stage in the chip testing process of the general-purpose chip testing pipeline. The complete description information of the chip testing environment is organized into five functional areas, each containing several fields. This allows for a complete and accurate description of the hardware environment, software environment, dependencies, and execution configuration required for chip software stack testing. It achieves structured standardization of field constraints in the chip testing domain and systematic abstraction of domain knowledge related to chip testing reproduction problems. This improves the completeness, accuracy, and standardization of configuration information in the chip test configuration file, facilitating the standardized expression and accurate reproduction of chip testing scenarios.

[0080] Specific application scenarios

[0081] To more clearly illustrate the technical solutions provided in the embodiments of the present invention, the embodiments of the present invention take the CI / CD pipeline as a general pipeline for chip testing as an example to specifically explain the chip test configuration file generation method provided in the embodiments of the present invention. Figure 3 This is a schematic diagram of the architecture of a chip test configuration file generation system provided by an embodiment of the present invention. In a specific example, such as... Figure 3 As shown, the chip test configuration file generation system can automatically generate chip test configuration files.

[0082] Specifically, such as Figure 3As shown, the CI / CD pipeline execution process comprises four stages: environment preparation, driver installation, software configuration, and test execution. Real-time status data generated in each stage is transmitted in real-time to the status capture module of the configuration instance generation tool below. The CI / CD pipeline execution process includes four main stages, and after each stage is completed, the status capture module automatically collects the status information for that stage. Specifically, in the environment preparation stage, system initialization, chip presence checks, and system dependency verification are performed. At this time, the status capture module collects AI chip hardware information through a hardware information collector, captures key environment variables within the host machine and container through an environment variable snapshotter, and records commands such as `system_check_cmd` and `target_check_cmd` through a command execution recorder. In the driver installation stage, the chip kernel driver module is installed, and driver parameters are set. At this time, the status capture module records the driver version through a software version recorder and records driver installation commands and parameters through a command execution recorder. In the software configuration stage, the container is started, the SDK and runtime library are installed, and environment variables are configured. At this stage, the status capture module records the container image version and SDK version using the software version recorder, and records commands such as `docker_launch_cmd` and `container_env_setup` using the command execution recorder. During the test execution phase, test cases are executed, and test results are collected. The status capture module then records the sequence of test commands executed at each stage (such as `target_check_cmd` and `kmd_install_cmd`) and core dump file path information using the command execution recorder. The data acquisition function of the status capture module is integrated into the CI / CD pipeline execution phase.

[0083] The configuration file generator of the configuration instance generation tool receives real-time status association information sent by the status capture module through a template filling engine. It extracts the corresponding key information and fills it into the corresponding fields of the five-area structure (metadata area, hardware environment description area, software environment description area, environment configuration area, and test execution description area) of the chip test configuration data specification, thus obtaining the initial chip test configuration file. For example, the template filling engine fills the driver installation command into the `software.kmd_install_cmd` field and the chip detection command into the `hardware.target_check_cmd` field. Furthermore, the configuration file generator verifies whether the configuration data in the initial chip test configuration file conforms to the specific specifications of the chip testing domain through a pattern validator. Finally, the configuration file generator serializes the verified initial chip test configuration file into a standardized chip test configuration file in JSON or YAML format using a file serializer and outputs it.

[0084] Correspondingly, the chip test configuration files automatically generated by the chip test configuration file generation system are self-describing configuration files. They adhere to specific specifications in the chip testing field, with clearly defined fields, a unified structure, and complete environment information, requiring no additional documentation or explanation. The chip test configuration files are not platform-specific and can be applied to different platforms to reproduce corresponding chip test scenarios. The chip test configuration file version is traceable; metadata fields such as `repo` or `job_url` can be used to trace back to the source code version and the corresponding pipeline task. During the generation of the chip test configuration file, the system can focus only on the processor architecture, network configuration, software version, and hardware status required for the pipeline to execute test tasks, without needing to concern itself with irrelevant information such as which cluster the machine is allocated from, how logs are uploaded, or how tasks are scheduled.

[0085] Compared to existing technologies, the aforementioned chip test configuration file generation method can automatically collect full state information of the chip test scenario during CI / CD pipeline execution and generate standardized, self-descriptive, and uniformly formatted chip test configuration files according to chip-specific configuration specifications. Optionally, the chip test configuration files automatically generated by the chip test configuration file generation system can serve as a contract interface between the "designer and user," allowing them to be read by external parsing devices and used for rapid and accurate reproduction of the chip test environment. Optionally, the chip test configuration file generation system can be deployed on any CI / CD pipeline platform, and the generated self-descriptive chip test configuration files have a uniform format, achieving decoupling from specific pipelines.

[0086] In the aforementioned chip test configuration file generation system, the CI / CD test pipeline can be designed and maintained by the pipeline designer (or configuration file producer). The pipeline designer can define test scenarios, such as selecting test cases, configuring test parameters, and setting the runtime environment. During pipeline execution, the chip test configuration file generation system automatically collects full status information from each stage of the CI / CD test pipeline and generates output chip test configuration files. These configuration files can include complete information required to reproduce the test scenario. Correspondingly, any engineer, such as a development engineer, test engineer, or technical support engineer, acting as a troubleshooter (or configuration file consumer), can obtain the standardized chip test configuration file generated by the system when they need to reproduce problems (such as test failures and program crashes) in the CI / CD pipeline in their local environment. This chip test configuration file can then be provided to the supporting device for parsing and execution, enabling one-click reproduction of the chip-specific test environment.

[0087] Figure 4 This is a schematic diagram of the data structure of a chip test configuration file provided in an embodiment of the present invention. In a specific example, such as... Figure 4 As shown, the data structure layout of the chip test configuration file configuration specification, from top to bottom, is as follows: Metadata area, including fields such as version, task identifier, repository and pipeline links; Hardware environment description area, including fields such as chip detection and system check commands; Software environment description area, including fields such as image, container, driver installation and container startup; Environment configuration area, including fields such as host machine and container environment settings; Test execution description area, including fields such as test command prefix, test list and core dump path. Each area's fields correspond one-to-one with specific constraints in the chip testing field, allowing the parsing system to automatically identify and execute them.

[0088] Optional, such as Figure 4 As shown, the chip test configuration file can also adapt and extend its data structure according to the testing requirements of specific chip types, such as adding a dependency description area structure (referred to as the dependency description area, dependencies). For example, the dependency description area structure can be configured with fields including, but not limited to, framework, framework_version, model_artifacts, and dataset_paths. The framework field can be used to specify the type of development framework or system framework, and framework_version can be used to specify the version number of the development framework or system framework. model_artifacts is a field applicable to AI chip types, used to configure all critical files and resources generated during model training, compilation, or deployment. The dataset_paths field refers to the path to the dataset file or folder.

[0089] In an optional embodiment of the present invention, the following is an example of a formal definition of a chip test configuration file (ChipTestConfig):

[0090] ChipTestConfig {

[0091] / / Metadata area - supports version control and source tracking

[0092] meta {

[0093] version: string / / Configuration specification version number

[0094] jobid: string / / Unique identifier for the task (supports variable substitution, e.g., {user}_{version})

[0095] repo: string / / Associated code repository

[0096] job_url: string / / URL of the associated CI / CD pipeline

[0097] cdash_url: string / / Test results dashboard URL

[0098] }

[0099] / / Hardware Environment Description Section - Chip-Specific Fields (Core Differentiation)

[0100] hardware {

[0101] target_check_cmd: list / / Chip detection commands (e.g., lspci for detecting GCU devices)

[0102] system_check_cmd: list / / System environment check command

[0103] }

[0104] / / Software environment description area - chip driver and runtime-specific configuration

[0105] software {

[0106] image: string / / Container image address

[0107] container: string / / Container name (supports variable substitution)

[0108] package_url: string / / Package download address

[0109] download_cmds: list / / Sequence of commands for downloading software packages

[0110] kmd_install_cmd: string / / Chip-specific: Driver installation command (including parameters such as --driver-y --no-auto-load)

[0111] docker_launch_cmd: list / / Container startup commands

[0112] container_env_prefix: string / / Prefix for container command execution

[0113] }

[0114] / / Environment Configuration Section - Host Machine and Container Environment Settings

[0115] environment {

[0116] host_env_setup: list / / Host environment setup commands

[0117] container_env_setup: list / / Commands for setting up the environment inside the container (such as SDK installation)

[0118] test_env_type: string / / Test environment type identifier

[0119] }

[0120] / / Test Execution Description Section - A complete description of the supported chip test scenarios

[0121] execution {

[0122] test_prefix: string / / Prefix for test commands

[0123] tests: list / / sequence of test commands

[0124] corefile: string / / Path to the core dump file (used for crash analysis)

[0125] }

[0126] }

[0127] In a specific example, the following example demonstrates how the five-zone structure of a chip test profile can fully describe all the environmental dependencies of an AI chip test scenario, enabling any engineer to accurately reproduce the AI ​​chip test environment in the CI / CD pipeline locally based on this profile.

[0128] {

[0129] "version": "1.0",

[0130] "repo": "ai-test",

[0131] "jobid": "{user}_topsinference_{version}",

[0132] "image": "ab.cn / enflame_docker_images / ubuntu / test_2004:1.1.1",

[0133] "container": "{user}_topsinference_{version}",

[0134] "job_url": "http: / / aaaaab / job / 12345",

[0135] "cdash_url": "http: / / aaaaac.com / test / 12345",

[0136] "package_url": "http: / / aaaaad.com / release / 3.6.105 / TopsRider.run",

[0137] "download_cmds": [

[0138] "wget -c --tries=5 {package_url}"

[0139] ],

[0140] "system_check_cmd": [

[0141] "mount | grep -E '.devtools|.distdir|tops'"

[0142] ],

[0143] "target_check_cmd": [

[0144] "lspci -d 1e36: | grep -i -E 'c033|c035|s60'"

[0145] ],

[0146] "host_env_setup": [],

[0147] "kmd_install_cmd": "ar .run --driver -y --no-auto-load",

[0148] "test_env_type": "inference",

[0149] "docker_launch_cmd": [

[0150] "efdocker run ci2004 --name {container}"

[0151] ],

[0152] "container_env_prefix": "docker exec -t {container} bash -c",

[0153] "container_env_setup": [

[0154] sudo bash TopsRider .run --container -C TopsInference -y"

[0155] ],

[0156] "corefile": "",

[0157] "test_prefix": "",

[0158] "tests": [

[0159] "topsinfo",

[0160] "python run_inference.py --model resnet50 --batch-size 32" ]

[0162] }

[0163] Table 1. Core Technical Features of Chip Test Configuration Files

[0164]

[0165] Table 1 is a list of core technical features of a chip test configuration file provided by an embodiment of the present invention. As shown in Table 1, the chip test configuration file provided by the embodiment of the present invention realizes a systematic abstraction of domain knowledge for describing chip-specific test environments, filling the gap in the lack of standardized configuration description language for chip test scenarios.

[0166] In summary, through automatically generated chip test configuration files, non-pipeline designers can quickly and accurately reproduce virtual chip test scenarios without needing to understand the internal implementation of the pipeline, thus lowering the reproduction threshold. Troubleshooters can obtain complete environment information through the chip test configuration files, reducing communication costs. Simultaneously, the standardized configuration format of the chip test configuration files ensures the integrity and consistency of the environment configuration, thereby improving the success rate of test reproduction. The same chip test configuration file can be reused across different pipeline platforms, supporting cross-platform migration. The specific data pattern format and field structure of the chip test configuration files are recognizable; programs or testing tools can directly and automatically read the configuration according to the fixed format, eliminating the need for manual line-by-line modification and achieving automated loading. This also reduces the probability of configuration errors, omissions, and incorrect entries, offering strong reusability and compatibility for expansion and upgrades.

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

[0168] It should be noted that any arrangement or combination of the technical features in the above embodiments also falls within the protection scope of this invention.

[0169] Example 3

[0170] Figure 5 This is a schematic diagram of a chip test configuration file generation device provided in Embodiment 3 of the present invention, as shown below. Figure 5 As shown, the device includes: a real-time status association information acquisition module 510 and a chip test configuration file generation module 520, wherein:

[0171] The real-time status association information acquisition module 510 is used to acquire real-time status association information of each test stage in the chip testing process of the general chip testing pipeline;

[0172] The chip test configuration file generation module 520 is used to generate a standardized chip test configuration file based on the real-time status association information.

[0173] This invention collects real-time status correlation information of a general chip testing pipeline during each testing stage of the chip testing process, and generates a standardized chip test configuration file based on the collected real-time status correlation information. This solves the problem that the general configuration file in the existing chip testing scenario cannot meet the chip-specific testing requirements, and can improve the completeness, accuracy and standardization of the configuration information in the chip test configuration file, which is conducive to the standardized expression and accurate reproduction of chip testing scenarios.

[0174] Optionally, the real-time status association information acquisition module 510 is also used to: acquire chip device hardware information during the environment preparation phase of the chip test pipeline; acquire chip software version association information during the driver installation phase of the chip test pipeline; acquire environment variable snapshot information during the software configuration phase of the chip test pipeline; and acquire test command execution record information during the test execution phase of the chip test pipeline.

[0175] Optionally, the chip test configuration file generation module 520 is further configured to: fill the preset data structure of the chip test configuration file according to the real-time status association information to obtain an initial chip test configuration file; perform normalization verification on the configuration data in the initial chip test configuration file; and, if the initial chip test configuration file is determined to pass the verification, serialize the initial chip test configuration file to obtain the standardized chip test configuration file.

[0176] Optionally, the chip test configuration file generation module 520 is further configured to: extract metadata fields from the real-time status association information and fill the metadata area structure of the chip test configuration file according to the metadata fields; extract chip hardware environment detection fields from the real-time status association information and fill the hardware environment description area structure of the chip test configuration file according to the chip hardware environment detection fields; extract chip software environment fields from the real-time status association information and fill the software environment description area structure of the chip test configuration file according to the chip software environment fields; extract environment configuration fields from the real-time status association information and fill the environment configuration area structure of the chip test configuration file according to the environment configuration fields; and extract test execution fields from the real-time status association information and fill the test execution description area structure of the chip test configuration file according to the test execution fields.

[0177] Optionally, the chip test configuration file generation module 520 is further configured to: verify the completeness of the required fields in the initial chip test configuration file; verify the correctness of the field types in the initial chip test configuration file; verify the validity of the chip-specific fields in the initial chip test configuration file; and verify the coverage of the necessary fields for the test scenario in the initial chip test configuration file.

[0178] Optionally, the chip test configuration file generation module 520 is further configured to: format and indent the initial chip test configuration file according to a set standard format; and add a configuration file generation timestamp and a generation system identifier to the initial chip test configuration file.

[0179] Optionally, the standardized chip test configuration file covers at least one of the following test scenarios: core dump analysis scenario, temporary file and working directory scenario, device test environment scenario, and library application programming interface (API) test scenario.

[0180] The chip test configuration file generation apparatus described above can execute the chip test configuration file generation method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in this embodiment can be found in the chip test configuration file generation method provided in any embodiment of the present invention.

[0181] Since the chip test configuration file generation apparatus described above is an apparatus capable of executing the chip test configuration file generation method in the embodiments of the present invention, those skilled in the art can understand the specific implementation and various variations of the chip test configuration file generation apparatus of this embodiment based on the chip test configuration file generation method described in the embodiments of the present invention. Therefore, how the chip test configuration file generation apparatus implements the chip test configuration file generation method in the embodiments of the present invention will not be described in detail here. Any apparatus used by those skilled in the art to implement the chip test configuration file generation method in the embodiments of the present invention falls within the scope of protection of this application.

[0182] Example 4

[0183] Figure 6 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0184] like Figure 6As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0185] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0186] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the chip test profile generation method.

[0187] Optionally, the chip test configuration file generation method may include: collecting real-time status association information of each test stage of a general chip test pipeline during chip testing; and generating a standardized chip test configuration file based on the real-time status association information.

[0188] In some embodiments, the chip test profile generation method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the chip test profile generation method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the chip test profile generation method by any other suitable means (e.g., by means of firmware).

[0189] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0190] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0191] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0192] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0193] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0194] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0195] This invention also discloses a computer program product, which includes a computer program that, when executed by a processor, implements the chip test configuration file generation method provided in any embodiment of this invention. This program product shares the same inventive concept as the chip test configuration file generation method disclosed in the embodiments of this invention, and therefore will not be described in detail here.

[0196] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the embodiments of the present invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in the embodiments of the present invention can be achieved, and this is not limited herein.

[0197] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for generating a chip test configuration file, characterized in that, include: Collect real-time status correlation information of each test stage in the chip testing process of a general chip testing pipeline; The initial chip test configuration file is obtained by filling the preset data structure of the chip test configuration file with the real-time status association information. A standardized chip test configuration file is generated based on the initial chip test configuration file; The preset data structure for filling the chip test configuration file based on the real-time status association information includes: Extract metadata fields from the real-time status association information, and populate the metadata area structure of the chip test configuration file according to the metadata fields; Extract the chip hardware environment detection field from the real-time status association information, and fill the hardware environment description area structure of the chip test configuration file according to the chip hardware environment detection field; Extract the chip software environment field from the real-time status association information, and fill the software environment description area structure of the chip test configuration file according to the chip software environment field; Extract the environment configuration field from the real-time status association information, and fill the environment configuration area structure of the chip test configuration file according to the environment configuration field; The test execution field is extracted from the real-time status association information, and the test execution description area structure of the chip test configuration file is filled according to the test execution field.

2. The method according to claim 1, characterized in that, The data acquisition includes real-time status correlation information of the general-purpose chip testing pipeline at each testing stage during chip testing, including: During the environmental preparation phase of the general-purpose chip testing pipeline, chip equipment hardware information is collected. During the driver installation phase of the general-purpose chip testing pipeline, chip software version association information is collected. During the software configuration phase of the chip testing pipeline, environmental variable snapshot information is collected. During the test execution phase of the general-purpose chip testing pipeline, test command execution record information is collected.

3. The method according to claim 1, characterized in that, The step of generating a standardized chip test configuration file based on the initial chip test configuration file includes: The configuration data in the initial chip test configuration file is standardized and verified. If the initial chip test configuration file is verified, the initial chip test configuration file is serialized to obtain the standardized chip test configuration file.

4. The method according to claim 3, characterized in that, The standardization and verification of the configuration data in the initial chip test configuration file includes: Verify the completeness of the required fields in the initial chip test configuration file; Verify the correctness of the field types in the initial chip test configuration file; The validity of the chip-specific fields in the initial chip test configuration file is verified; wherein, the chip-specific fields include chip detection command fields, system environment check command fields, and driver installation command fields.

5. The method according to claim 3, characterized in that, The step of serializing the initial chip test configuration file includes: The initial chip test configuration file is formatted and indented according to a set standard format; Add a configuration file generation timestamp and generation system identifier to the initial chip test configuration file.

6. The method according to claim 1, characterized in that, The standardized chip test configuration file covers at least one of the following test scenarios: core dump analysis scenario, temporary file and working directory scenario, device test environment scenario, and library application programming interface (API) test scenario.

7. A chip test configuration file generation device, characterized in that, include: The real-time status association information acquisition module is used to collect real-time status association information of the chip testing pipeline at each testing stage during chip testing. The chip test configuration file generation module is used to fill the preset data structure of the chip test configuration file according to the real-time status association information to obtain an initial chip test configuration file; and to generate a standardized chip test configuration file according to the initial chip test configuration file. The chip test configuration file generation module is also used to: extract metadata fields from the real-time status association information, and fill the metadata area structure of the chip test configuration file according to the metadata fields; Extract the chip hardware environment detection field from the real-time status association information, and fill the hardware environment description area structure of the chip test configuration file according to the chip hardware environment detection field; extract the chip software environment field from the real-time status association information, and fill the software environment description area structure of the chip test configuration file according to the chip software environment field; extract the environment configuration field from the real-time status association information, and fill the environment configuration area structure of the chip test configuration file according to the environment configuration field. The test execution field is extracted from the real-time status association information, and the test execution description area structure of the chip test configuration file is filled according to the test execution field.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that is executed by the at least one processor, such that the at least one processor is able to perform the chip test configuration file generation method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the chip test configuration file generation method according to any one of claims 1-6.

10. A computer program product, characterized in that, It includes a computer program / instruction, wherein the computer program / instruction, when executed by a processor, implements the chip test configuration file generation method according to any one of claims 1-6.

Images