A method, apparatus, medium, and product for automatically generating an atomic test model

Abstract

This invention discloses a method, device, medium, and product for automatically generating atomic test models, relating to the fields of atomic testing and chip technology. The method includes: acquiring an atomic characteristic requirement table adapted to a target hardware chip and parsing it to obtain structured intermediate data matching its computational capabilities; generating computational description reference data based on computational dimension information related to the target hardware chip; dynamically filling and compiling code template resources using the computational description reference data; and assembling the atomic computation model in a component-based and hierarchical manner according to the architecture level of the target hardware chip. This enables the generated atomic test model to adapt to the chip architecture, while reducing the adaptation cost between the model and the chip, improving the accuracy and reliability of atomic testing, and thus achieving automated and standardized generation of atomic test models. It adapts to the atomic testing needs of target hardware chips of different specifications, providing efficient and convenient technical support for chip-level atomic computation testing.

Description

Technical Field

[0001] This invention relates to the fields of atomic testing and chip technology, and in particular to a method, apparatus, medium and product for automatically generating atomic testing models. Background Technology

[0002] Atomic operations, due to their inherent indivisible execution process, enable data synchronization and data reduction computation between multi-core processors. During the chip requirements development phase, the atomic semantics and data types supported by each atomic emission device are defined independently to adapt to various AI (Artificial Intelligence) chips and SoC (System on Chip) atomic operation testing application scenarios.

[0003] The current development model for atomic test models in SoC systems relies on manual conversion from design requirements to test models throughout the entire process. This manual approach involves writing, adapting, and building atomic test models to meet the test modeling needs of different chip atomic semantics and data types. However, this manual-driven development method is susceptible to human error, introducing design and modeling risks. Furthermore, it suffers from poor adaptability to changes in chip atomic requirements, high development and maintenance costs, and reduced verification efficiency and reliability. Summary of the Invention

[0004] This invention provides a method, device, medium, and product for automatically generating atomic test models, in order to solve the problems of poor adaptability of atomic test models, high development and maintenance costs, and low efficiency and reliability of atomic test verification.

[0005] According to one aspect of the present invention, a method for automatically generating an atomic test model is provided, comprising: Obtain and parse the atomic characteristic requirement table that is compatible with the target hardware chip to obtain the structured intermediate data required for the atomic operation model that matches the computing power of the target hardware chip. Based on structured intermediate data and atomic characteristic requirement tables, the computational dimension information related to the target hardware chip is associated, summarized and mapped to generate computational description reference data. Based on the operation description reference data, the preset code template resources are dynamically populated and compiled and configured to generate definition header files, interface declaration header files, function implementation source files and build configuration files that match the atomic operation model of the target hardware chip; Based on the definition header file, interface declaration header file, function implementation source file, and build configuration file, the atomic operation model is modularized and hierarchically assembled according to the architecture level of the target hardware chip to obtain the atomic test model.

[0006] According to another aspect of the present invention, an apparatus for automatically generating atomic test models is provided, comprising: The requirement parsing module is used to obtain and parse the atomic characteristic requirement table that is compatible with the target hardware chip, and obtain the structured intermediate data required for the atomic operation model that matches the computing power of the target hardware chip. The association mapping module is used to associate, summarize and map computational dimension information related to the target hardware chip based on structured intermediate data and atomic characteristic requirement tables, and generate computational description reference data. The file generation module is used to dynamically populate and compile the preset code template resources according to the operation description reference data, and generate definition header files, interface declaration header files, function implementation source files and build configuration files that match the atomic operation model of the target hardware chip. The hierarchical assembly module is used to perform component-based and hierarchical assembly of the atomic operation model according to the architecture hierarchy of the target hardware chip, based on the definition header file, interface declaration header file, function implementation source file and build configuration file, to obtain the atomic test model.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the method for automatically generating atomic test models according to any embodiment of the present invention.

[0008] 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 method for automatically generating atomic test models according to any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the method as described in any embodiment of the present invention.

[0010] The technical solution of this invention, by acquiring an atomic characteristic requirement table adapted to the target hardware chip and parsing it to obtain structured intermediate data matching its computing capabilities, ensures that the generated intermediate data matches the chip hardware characteristics, avoiding model compatibility issues caused by data mismatch. Based on the computing dimension information related to the target hardware chip, it generates computational description reference data, capturing the chip's computational requirements and constraints, providing guidance for subsequent code generation that aligns with the chip's actual needs. By dynamically filling and compiling code template resources with the computational description reference data, it can quickly generate various files adapted to the target hardware chip, reducing the workload of manual code writing and adaptation, and improving model generation efficiency. By modularizing and hierarchically assembling the atomic computation model according to the target hardware chip's architecture, it enables the generated atomic test model to adapt to the chip architecture, ensuring that the model can run stably and efficiently on the target hardware chip after deployment. This also reduces the adaptation, development, and maintenance costs between the model and the chip, improves the accuracy and reliability of atomic testing, and ultimately achieves automated and standardized generation of atomic test models, adapting to the atomic testing needs of different target hardware chips, providing efficient and convenient technical support for chip-level atomic computation testing, and improving verification efficiency.

[0011] 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

[0012] 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.

[0013] Figure 1 This is a flowchart of a method for automatically generating an atomic test model according to Embodiment 1 of the present invention; Figure 2 This is a flowchart of another method for automatically generating atomic test models according to Embodiment 2 of the present invention; Figure 3 This is a flowchart of another method for automatically generating atomic testing models according to Embodiment 3 of the present invention; Figure 4 This is a flowchart illustrating an automatic generation system for atomic testing models applicable to an embodiment of the present invention. Figure 5 This is a schematic diagram illustrating the automatic generation of an atomic testing model applicable to an embodiment of the present invention; Figure 6 This is a schematic diagram of the working of an atomic testing model applicable to an embodiment of the present invention; Figure 7 This is a schematic diagram of the structure of an apparatus for automatically generating atomic testing models according to Embodiment 4 of the present invention; Figure 8 This is a schematic diagram of the structure of an electronic device that implements the method for automatically generating atomic test models according to embodiments of the present invention. Detailed Implementation

[0014] 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. 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.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Example 1 Figure 1 This is a flowchart of a method for automatically generating atomic test models according to Embodiment 1 of the present invention. This embodiment is applicable to the automatic generation of atomic test models. The method can be executed by a device for automatically generating atomic test models. This device can be implemented in hardware and / or software and is generally configured in an electronic device. Figure 1 As shown, the method includes: S110. Obtain and parse the atomic characteristic requirement table that is compatible with the target hardware chip to obtain the structured intermediate data required for the atomic operation model that matches the computing power of the target hardware chip.

[0017] In this embodiment of the invention, the atomic characteristic requirement table can be specifically understood as: a configuration file that defines the atomic operation types, data types, data bit widths, and other characteristics supported by the target hardware chip in tabular form, serving as the input basis for model generation. The structured intermediate data can be specifically understood as: converting the unstructured information in the table into standard format data with hierarchical and key-value relationships, providing a unified data foundation for subsequent code generation. The target hardware chip's computing power can be specifically understood as: the hardware-level computational constraints and capability boundaries, such as the atomic operation types, data bit width ranges, and data types supported by the target chip.

[0018] Specifically, the atomic characteristic requirement table adapted to the target hardware chip is read and parsed. Using a script engine or dedicated parsing tool, such as a Python engine, the structured data required by the atomic operation model is extracted. The information such as atomic operation type, data type, and data bit width defined in the table is converted into a structured form, such as a tree-like hierarchical key-value pair format. Here, the atomic operation type can be the first-level node, each data type can be the second-level node, and each data bit width can be the list value under the corresponding data type, forming structured intermediate data that matches the computing capabilities of the target hardware chip.

[0019] The specific format for the output data can be as follows: This JSON structure is a hierarchical data structure organized in key-value pairs. The top level has master_name as the root node, which represents the overall identifier of a target hardware chip or atomic emission device, used to uniquely identify the hardware object to which the current configuration belongs.

[0020] It contains multiple atomic operation type nodes (such as op_type0, op_type1), which represent the specific atomic operation types supported by the target hardware chip (such as addition, subtraction, AND, OR, maximum value, minimum value, etc.). Different key names correspond to different operation types.

[0021] Each operation type node contains a nested data_type field. The data_type field is a data type configuration node, which is a child node under each atomic operation type. It is used to define all the data types and their bit widths supported by the atomic operation.

[0022] The data_type field contains multiple data type values ​​(such as data_type_value0, data_type_value1), representing specific data type values, such as signed numbers, unsigned numbers, floating-point numbers, etc. Different key names correspond to different data types.

[0023] Each data type value corresponds to an array, which stores the different data bit widths supported by that data type (such as data_type0width0, data_type0width1, data_type0width2, etc.), representing the different bit width specifications supported by the corresponding data type (such as 8 bits, 16 bits, 32 bits, 64 bits, etc.). It is stored in list form to facilitate subsequent traversal and code generation.

[0024] Optionally, based on the above embodiments, obtaining and parsing an atomic characteristic requirement table adapted to the target hardware chip to obtain structured intermediate data required for an atomic operation model matching the computing power of the target hardware chip may include: Obtain the atomic characteristic requirement table and read its worksheet content, extracting the atomic operation type, data type, and data bit width information; convert the above information into structured intermediate data in key-value pair form.

[0025] In this embodiment of the invention, the worksheet content can be specifically understood as: the work page storing specific requirement parameters within the atomic characteristic requirement table, serving as a carrier of requirement information. The atomic operation type can be specifically understood as: the atomic operations supported by the target hardware chip, which can be further categorized according to semantics and response mode into multiple types: comparison condition submission atomic operations, exchange atomic operations, as well as arithmetic operations, bitwise logical operations, extreme value operations, and unary step-up update operations, etc. Among these, arithmetic operations (such as addition and subtraction), bitwise logical operations (such as AND, OR, and XOR), extreme value operations (such as maximum and minimum values), and unary step-up update operations (such as increment and decrement) can be further divided into old value return type and old value non-return type according to their response type. The old value refers to the original value participating in the operation before execution. Taking addition as an example, it can be specifically divided into old value return type addition operations and old value non-return type addition operations, used to return or not return the original data value before the operation, respectively.

[0026] Comparison-conditional atomic operations can be understood as Compare-and-Swap (CAS) operations. These are atomic operations that first determine the condition before execution. They read the current value at a memory location and compare it with the expected value. If they are equal, the value at that location is atomically updated to the new value; otherwise, no update is performed, and the current actual value is returned. The atomicity of this comparison-update process is guaranteed by hardware and can be used to implement lock-free concurrency control, data structure synchronization, and other scenarios, avoiding race conditions. Swap-type atomic operations can be understood as operations that directly perform atomic read-write-replacement of memory values. They read the current value at a memory location and simultaneously write a new value atomically to that location. The entire read-write process is indivisible. These operations do not require conditional checks and directly swap the old and new values. They can be used to quickly implement data exchange between threads, lock state switching, and other scenarios, and are one of the atomic operations for achieving concurrency synchronization.

[0027] Data type can be specifically understood as the format type of the data processed by atomic operations, such as unsigned numbers, signed numbers, etc. Data bit width can be specifically understood as the bit width specification of the data processed by atomic operations, such as 32-bit, 64-bit, etc., matching the granularity of chip hardware operations.

[0028] Specifically, the process involves obtaining a table of atomic characteristic requirements compatible with the target hardware chip and reading its contents. From this table, the types of atomic operations supported by the target hardware chip are extracted. These include comparison-conditional commit atomic operations, exchange atomic operations, arithmetic operations, bitwise logical operations, extreme value operations, and unary step-up update operations. Arithmetic operations cover addition and subtraction, bitwise logical operations cover AND, OR, and XOR, extreme value operations cover maximum and minimum values, and unary step-up update operations cover increment and decrement. This achieves full coverage of basic types of atomic operations such as read, write, replace, and comparison-replace, as well as various extended semantic atomic operations. Simultaneously, the corresponding data type and data bit width information are extracted, converting the unstructured text information in the table into structured intermediate data in key-value pair format. This structured intermediate data provides the data foundation for subsequent computational description generation, describing the core information such as the operation types and data types supported by the model, for the next step of generating model computational side description information. Furthermore, information extraction and conversion can also be achieved by reading configuration files and obtaining requirement parameters through interface calls.

[0029] Taking an atomic characteristic requirement table adapted to the target hardware chip as input and parsing its contents, the atomic operation type, data type, and data bit width information are extracted and converted into structured intermediate data in key-value pair format. This unifies the scattered and unstructured chip atomic characteristic requirement information into a standardized, hierarchical key-value pair format, enabling subsequent steps such as operation description generation and code template filling to read and use this data in a standardized manner. This avoids model adaptation deviations caused by inconsistent information formats or incomplete information, while reducing the workload of manually sorting and entering requirement information, lowering the risk of human error, and ensuring that the generated structured intermediate data is highly matched with the computing power of the target hardware chip. This provides an accurate and reliable data foundation for the subsequent generation of atomic operation models adapted to the chip, improves the standardization and consistency of atomic test model development, and lays the foundation for the automated and efficient generation of atomic test models adapted to different hardware chip specifications.

[0030] S120. Based on the structured intermediate data and atomic characteristic requirement table, the computational dimension information related to the target hardware chip is associated, summarized and mapped to generate computational description reference data.

[0031] In this embodiment of the invention, the computational dimension information can be specifically understood as: related information such as atomic operation types, data categories, data bit widths, and computational constraints associated with the target hardware chip. The computational description reference data can be specifically understood as: standardized intermediate data used to guide code generation and model construction, which may specifically include: chip computational rules and configuration information.

[0032] S130. Based on the operation description reference data, dynamically fill and compile the preset code template resources to generate definition header files, interface declaration header files, function implementation source files and build configuration files that match the atomic operation model of the target hardware chip.

[0033] In this embodiment of the invention, the code template resource can be specifically understood as: predefined template files such as code frameworks, interface formats, and function structures.

[0034] S140. Based on the definition header file, interface declaration header file, function implementation source file and construction configuration file, the atomic operation model is componentized and hierarchically assembled according to the architecture level of the target hardware chip to obtain the atomic test model.

[0035] In this embodiment of the invention, the atomic test model can be specifically understood as: a complete atomic operation test model that can be directly compiled, simulated, and deployed to a chip for execution.

[0036] Specifically, based on structured intermediate data and atomic characteristic requirement tables, the extracted atomic operation types, data types, data bit widths, and other computational dimension information are matched and cross-validated item by item according to the computational rules and hardware constraints of the target hardware chip to determine the legal combination relationship between each computational dimension. The above combination information is classified, organized, and summarized according to operation category, data format, and bit width specification. By establishing key-value correspondence, atomic operations, data types, data bit widths, and information such as underlying computing resources and macro definition identifiers are mapped one by one to form a complete and accurate association matching relationship between computational dimensions.

[0037] The relationships between computational dimensions are uniformly encapsulated and formatted according to the preset data structure and storage specifications. Redundant information is removed and the configuration parameters and identification information required for model construction are added to form standardized and structured data containing information such as data category, bit width, operation category, macro-level symbols and operation mapping relationships. Standardized computational description reference data that can be directly used to guide code template filling and model assembly is generated.

[0038] Based on the operation description reference data, the system calls the preset code template resources and automatically replaces and dynamically fills the placeholder variables defined therein with the corresponding data category, bit width, operation category, macro symbol and operation mapping relationship in the operation description reference data. It also completes the compilation configuration processing according to the compilation environment and runtime constraints of the target hardware chip, and automatically generates the definition header file, interface declaration header file, function implementation source file and build configuration file that match the atomic operation model of the target hardware chip.

[0039] Based on the generated definition header files, interface declaration header files, function implementation source files, and build configuration files, according to the architecture hierarchy and functional division of the target hardware chip, the data type definitions, interface declarations, operation execution logic, and underlying operator calls related to atomic operations are modularly decomposed and abstracted to form independent and reusable functional components. Then, through automated build tools, interface interfaces, logical associations, and overall assembly of each functional component are performed according to the chip's hierarchical architecture. Relying on the definitions, implementations, and configurations provided by various files, the hierarchical construction of the atomic test model is completed, resulting in a standardized atomic test model that can be directly compiled, simulated, and run.

[0040] It is important to emphasize that the atomic operation model is an underlying logical model abstracted from the atomic characteristics requirements of the target hardware chip. It is used to characterize the chip's native atomic operation capabilities and operation rules. It focuses on defining atomic operation types, data types, bit widths, and underlying operator mapping relationships, and belongs to the hardware capability logical abstraction layer.

[0041] The atomic test model is a compilable, simulable, and chip-running entity test model built upon the atomic operation model. It relies on structured intermediate data generated through parsing, operation description reference data, and various definition header files, interface files, implementation source files, and build configuration files. It focuses on functional verification of atomic operation logic, transaction data processing, and operation result determination. The atomic operation model provides the underlying logic specifications and capability definitions for the atomic test model, serving as the basis and foundation for its construction. The atomic test model represents the engineered and runnable implementation of the atomic operation model for chip testing scenarios.

[0042] The technical solution of this invention, by acquiring an atomic characteristic requirement table adapted to the target hardware chip and parsing it to obtain structured intermediate data matching its computing capabilities, ensures that the generated intermediate data matches the chip hardware characteristics, avoiding model compatibility issues caused by data mismatch. Based on the computing dimension information related to the target hardware chip, it generates computational description reference data, capturing the chip's computational requirements and constraints, providing guidance for subsequent code generation that aligns with the chip's actual needs. By dynamically filling and compiling code template resources with the computational description reference data, it can quickly generate various files adapted to the target hardware chip, reducing the workload of manual code writing and adaptation, and improving model generation efficiency. By modularizing and hierarchically assembling the atomic computation model according to the target hardware chip's architecture, it enables the generated atomic test model to adapt to the chip architecture, ensuring that the model can run stably and efficiently on the target hardware chip after deployment. This also reduces the adaptation, development, and maintenance costs between the model and the chip, improves the accuracy and reliability of atomic testing, and ultimately achieves automated and standardized generation of atomic test models, adapting to the atomic testing needs of different target hardware chips, providing efficient and convenient technical support for chip-level atomic computation testing, and improving verification efficiency.

[0043] Example 2 Figure 2 This is a flowchart of another method for automatically generating atomic test models provided in Embodiment 2 of the present invention. This embodiment is a refinement of the above embodiment's step of "based on structured intermediate data and atomic characteristic requirement tables, performing association, summarization, and mapping processing on computational dimension information related to the target hardware chip to generate computational description reference data." Figure 2 As shown, the method includes: S210. Obtain and parse the atomic characteristic requirement table that is compatible with the target hardware chip to obtain the structured intermediate data required for the atomic operation model that matches the computing power of the target hardware chip.

[0044] S220. Based on the structured intermediate data and atomic characteristic requirement table, summarize the correspondence between data categories, bit widths, operation categories, and macro-level symbols according to preset rules, and generate operation description reference data.

[0045] In this embodiment of the invention, macro symbols can be specifically understood as macro-defined identifiers used at the code level to identify information such as data types, operation attributes, and hardware configurations.

[0046] Specifically, according to pre-set classification standards, matching logic, and mapping rules, data types, data bit widths, atomic operation types, and macro symbols are extracted from structured intermediate data and atomic characteristic requirement tables. Using atomic operation types as the main index, the supported data types and corresponding data bit widths are matched and bound. Then, a unique macro symbol identifier is assigned to each combination of data type and operation type. The association mapping relationship between operation type and data type, data type and data bit width, type operation combination and macro symbol is established in sequence. All dimension combination information is classified, deduplicated, and summarized to form a set of overall mapping relationships with logical correspondence and hierarchical association between various elements.

[0047] In a specific example, the atomic characteristic requirement table is the original requirement table provided by the chip design team. It defines the atomic operation capabilities of the target hardware chip in a structured table format, as shown in Table 1. The Engine column identifies the hardware module, the oper_type column defines the atomic operation type (such as the addition operation in arithmetic operations), and the data_type column lists the various data types supported by the operation (such as INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, FP8, FP16, FP32, FP64, TF16, BF16, etc.). The table uses "Y (yes), N (no), unmarked (no)" to indicate whether the combination of each data type and atomic operation is supported by the hardware, presenting the adaptation of various data types under different atomic operations, and providing a parsable original requirement basis for subsequent parsing and generation of structured intermediate data. Among them, INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, and UINT64 represent 8-bit, 16-bit, 32-bit, and 64-bit signed (INT) or unsigned (UINT) integer data types, respectively, used to define the bit width and sign attribute of the integer data processed by atomic operations; FP8, FP16, FP32, FP64, TF16, and BF16 are floating-point data type identifiers, corresponding to 8-bit floating-point, 16-bit half-precision floating-point, 32-bit single-precision floating-point, 64-bit double-precision floating-point, 16-bit tensor floating-point, and 16-bit double-precision floating-point, respectively, covering floating-point operation scenarios of different precisions; LDST (Load / Store) represents the ability to return or not return old value data in atomic operations, where Load represents returning old value data, and Store represents not returning old value data, thus indicating whether the original data value before the operation needs to be returned during the execution of the atomic operation.

[0048] SUPPORT is a hardware support identifier, marked in the form of "Y / N" to indicate whether the combination of the corresponding atomic operation and data type is supported by the target hardware chip; Store Only is an operation type restriction identifier, indicating that the atomic operation only supports the type of old value data not returned, and does not support the type of old value data returned, which belongs to the restricted atomic operation type.

[0049] Table 1 In a specific example, the computation description reference data generation is based on structured intermediate data and an atomic characteristic requirement table. It summarizes the bit width, operation category, and macro-level correspondences under each data category according to preset rules, outputting computation description reference data as the sole reliable computation dimension reference for subsequent code generation. Its format is shown in Table 2, defined by columns: label, data type, data bit width, operation type, and operation macro label. In practical applications, the string example content in the second row will be replaced with actual hardware parameter data, providing a standardized computation dimension mapping basis for subsequent code template filling and model construction. Here, DTYPE represents the data type, used to identify the data format supported by the atomic operation; width1, width2, and width3 represent different data bit width specifications supported under this data type; OP_TYPE represents the atomic operation type, used to identify the specific atomic operation category; and OP_DTYPE_INDEX is the mapping index between operations and data types, used to establish a unique association between atomic operations, data types, and corresponding bit widths, providing a computation dimension reference basis for subsequent code generation.

[0050] Table 2 S230. Based on the operation description reference data, dynamically fill and compile the preset code template resources to generate definition header files, interface declaration header files, function implementation source files and build configuration files that match the atomic operation model of the target hardware chip.

[0051] S240: Based on the definition header file, interface declaration header file, function implementation source file and construction configuration file, the atomic operation model is componentized and hierarchically assembled according to the architecture level of the target hardware chip to obtain the atomic test model.

[0052] The technical solution of this invention avoids model compatibility issues caused by data mismatch by obtaining an atomic characteristic requirement table adapted to the target hardware chip and parsing it to obtain structured intermediate data matching its computing capabilities. The structured intermediate data is the basic data matching the computing capabilities of the target hardware chip obtained by parsing the atomic characteristic requirement table. The atomic characteristic requirement table directly carries the atomic operation-related requirements of the target hardware chip. The combination of the two ensures that the summarized information revolves around the target hardware chip. According to preset rules, the correspondence between data categories, bit widths, operation categories, and macro-level symbols is summarized and mapped, enabling the systematic integration of scattered chip-related computing information. This allows the generated computing description reference data to present the logical relationships between various computing dimensions, capturing the computing requirements and hardware constraints of the target hardware chip. This provides precise guidance for the subsequent dynamic filling and compilation configuration of code template resources based on this computing description reference data, avoiding code generation deviations caused by chaotic computing dimension information and unclear relationships. It reduces the workload of manually sorting out the relationships between computing dimensions, improves the accuracy and efficiency of subsequent code generation, and lays a reliable data foundation for the component-based and hierarchical assembly of atomic test models. By dynamically populating and compiling code template resources with computational description reference data, and assembling atomic operation models in a componentized and hierarchical manner according to the architecture level of the target hardware chip, this provides efficient and convenient technical support for chip-level atomic operation testing and improves verification efficiency.

[0053] Example 3 Figure 3 This is a flowchart of another method for automatically generating atomic test models provided in Embodiment 3 of the present invention. This embodiment is a refinement of the above embodiment's step of "dynamically filling and compiling preset code template resources according to operation description reference data to generate definition header files, interface declaration header files, function implementation source files, and construction configuration files that match the atomic operation model of the target hardware chip." Figure 3 As shown, the method includes: S310. Obtain and parse the atomic characteristic requirement table that is compatible with the target hardware chip to obtain the structured intermediate data required for the atomic operation model that matches the computing power of the target hardware chip.

[0054] Furthermore, based on the above embodiments, before obtaining the atomic characteristic requirement table adapted to the target hardware chip, the following may also be included: The system reads the project configuration parameters, directory path, and atomic characteristic requirement table path, and parses the atomic characteristic requirement table path to obtain the command list and supporting documentation for the solidified overall pipeline. The command list for the solidified overall pipeline is used to control the process of automatically generating atomic test models, while the supporting documentation is used to explain the command list and the overall generation process.

[0055] In this embodiment of the invention, the project configuration parameters can be specifically understood as: global configuration information including target hardware chip environment configuration, compilation options, path definitions, etc. The directory path can be specifically understood as: the system path storing resources such as code templates, generated files, and toolchains. The atomic characteristic requirement table path can be specifically understood as: the file storage path pointing to the atomic characteristic requirement table.

[0056] The command list for the solidified overall pipeline can be understood as a predefined set of automated scripts or instructions used to execute each step of the atomic test model generation process sequentially. The accompanying documentation can be understood as a descriptive document recording the usage of the command list, parameter descriptions, and the generation process.

[0057] Specifically, before obtaining the atomic characteristic requirement table adapted to the target hardware chip, a pre-configuration process can be executed: after reading the project configuration parameters, directory path, and atomic characteristic requirement table path, the path information is parsed and verified by a configuration parsing tool, the preset pipeline script template is automatically identified and loaded, and a command list containing the full process instructions for generating the atomic test model is generated based on the project environment parameters of the target hardware chip. At the same time, based on the configuration information and process definition, a supporting documentation recording the command usage, parameter meaning, and execution order is generated, thereby obtaining a command list and documentation for a controllable automatic generation process. This provides pre-configuration support for the subsequent acquisition and parsing of the atomic characteristic requirement table, ensuring the automation and reproducibility of the entire process.

[0058] In a specific example, the project configuration (including project configuration parameters, directory path, and atomic characteristic requirement table path) for the automatic generation process of atomic test models can be formatted as follows: The `model_gen_cfg` dictionary defines the core paths and parameters required for model generation. `ProjRoot` is the project root directory, `spec_dir` specifies the storage path for the atomic requirement table, `doc`, `model`, and `Json_File` are the output directories for the accompanying documentation, the generated model files, and the structured data, respectively, `template` is the storage directory for the code template, and `SheetName` and `JSON_Name` are the worksheet name for the atomic requirement table and the output file name for the structured data, respectively, providing unified path and configuration support for subsequent processes.

[0059] The output list of commands for the solidified overall pipeline is a record of commands that convert the entire atomic test model generation chain into build and compilation control files such as Makefiles that can be executed directly. This ensures that the commands can be executed repeatedly in the same configuration environment and produce consistent output results. The accompanying documentation is a user manual corresponding to the current project path and execution steps.

[0060] By pre-reading and parsing the engineering configuration parameters, directory paths, and table paths before obtaining the atomic characteristic requirement table, a command list and supporting documentation for the solidified overall pipeline can be generated. This enables standardized and automated control of the atomic test model generation process. It not only ensures process consistency and result reproducibility under different execution environments and reduces manual configuration errors and repetitive execution costs, but also provides path guidance and process constraints for subsequent requirement analysis, model generation, and other stages, thereby improving the reliability, maintainability, and engineering sophistication of the entire atomic test model generation process.

[0061] S320. Based on structured intermediate data and atomic characteristic requirement tables, the computational dimension information related to the target hardware chip is associated, summarized, and mapped to generate computational description reference data.

[0062] S330. Call the preset template library, and based on the operation description reference data, perform replacement processing on the placeholders in the template library to generate macro and type definition header files, model declaration header files, model implementation source files, and construction description files.

[0063] In this embodiment of the invention, the template library can be specifically understood as a pre-written generic file skeleton with reserved placeholders, which may specifically include the fixed format and syntax structure of files such as header files, source files, and build files. Placeholders can be specifically understood as reserved markers in the template to be filled, used to match information such as data type, bit width, and operation macros.

[0064] Specifically, the pre-designed template library file is loaded, and key information such as data type, bit width, operation type, macro-level mapping index, interface declaration information, operation implementation logic information, and project construction rule information are extracted from the operation description reference data. The data type, bit width information, and macro-level mapping index information are matched and filled into the placeholder positions of the type definition template to generate macro and type definition header files. The operation type and interface declaration information are matched and filled into the placeholder positions of the declaration template to generate model declaration header files. The operation implementation logic information is combined with the data type and operation type to fill into the placeholder positions of the function implementation template to generate model implementation source files. The project construction rule information is matched and filled into the placeholder positions of the construction configuration template to generate construction description files. The dynamic rendering of the template content is completed, and finally four types of project files are generated.

[0065] Among them, macro and type definition header files serve as basic definition header files, model declaration header files serve as external interface declaration header files, model implementation source files serve as core function implementation source files, and build description files serve as project build configuration files. At the same time, dynamic template engines or custom script generation methods can be flexibly selected according to the target chip architecture, so that the file format and content structure can be adapted to diverse hardware platforms, improving the adaptability and expansion efficiency of code generation.

[0066] In a specific example, the template library is mainly used to provide basic templates in the process of generating computational models. The template content includes two parts: common inherent information that does not change with requirements and variable information identified by special placeholders such as %auto_gen%, %insert%, etc. Overall, it is divided into three categories: header file templates, model basic component templates, and construction templates. Taking the log function declaration template as an example, such as "bool log_info(std::string msg,uint32_t verbosity);bool log_error(std::string msg,uint32_t severity);%auto_gen%". In the code "bool log_info(std::string msg,uint32_t verbosity);", msg represents the log message string to be output, and verbosity represents the redundancy level of the log printing; in the code "bool log_error(std::string msg,uint32_t severity);", msg represents the error message string, severity represents the error severity level, std::string represents a string, and uint32_t represents an unsigned 32-bit integer.

[0067] The logging interface function declarations in the first two lines are fixed and unchanging inherent information, while the % auto_gen% position is used to automatically fill in dynamically changing code content based on the operation description reference data, thereby achieving the standardization and automated generation of code files.

[0068] Both of these functions are log declaration interfaces and belong to the header file template category in the template library. In addition, the template library may also contain type definition header file templates for defining atomic operation types and macros, model declaration header file templates for declaring operation interfaces, function implementation source file templates for implementing operation logic, Makefile build configuration templates for configuring project compilation rules, and model basic component templates for encapsulating basic operation logic, etc.

[0069] Optionally, based on the above embodiments, generating macro and type definition header files may include: Based on the operation description reference data and the atomic characteristic requirement table, generate macro and type definition header files that include operation class macro enumeration values, data type numerical macros, and user-visible operation type macros.

[0070] In this embodiment of the invention, the operation-type macro enumeration value can be specifically understood as: an enumeration constant used to identify different atomic operations, such as operation numbers for addition, multiplication, comparison, etc. The data type numerical macro can be specifically understood as: a macro constant defining the data types (such as integer, floating-point, etc.) supported by the chip, used to distinguish data formats. The user-visible operation type macro can be specifically understood as: an operation type macro exposed externally for use by upper layers.

[0071] Specifically, when generating macro and type definition header files, the system takes the generated operation description reference data and atomic characteristic requirement table as input, extracts core information such as operation category, data type, bit width specification, macro-level mapping index, and operation identifier, and converts this information into standardized enumeration values ​​and macro definitions according to preset naming conventions and mapping rules. Operation categories are mapped to operation-class macro enumerations, data types and bit width specifications are mapped to data type numeric macros, and operation identifiers and macro-level mapping indices are mapped to user-visible operation type macros. These are then uniformly populated into the macro and type definition header file template, ultimately generating a macro and type definition header file containing operation-class macro enumeration values, data type numeric macros, and user-visible operation type macros. This provides a unified and unique symbolic basis for conditional compilation, branch judgment, and operator numbering in the model header file and implementation file. In addition to directly generating fixed macro definitions, the system can dynamically adjust macro naming rules, enumeration value allocation methods, and type definition formats according to the instruction sets, data formats, and compilation environments of different hardware architectures, achieving multi-chip platform compatibility and further improving code portability, versatility, and maintenance efficiency.

[0072] By generating macro and type definition header files based on operation description reference data and atomic characteristic requirement tables, including operation class macro enumeration values, data type numerical macros, and user-visible operation type macros, a unified and standardized symbol definition and type identifier is provided for the atomic operation model. This avoids problems such as poor readability and error susceptibility caused by hard-coded numerical values. At the same time, it ensures that the code has a consistent referencing standard when conditionally compiling, branching, and operator numbering, thereby improving the maintainability, readability, and stability of the code and providing a foundation for subsequent model declaration, function implementation, and engineering construction.

[0073] Optionally, based on the above embodiments, generating a model declaration header file may include: Based on the mapping table from data types to computation modules in the computation description reference data, and the model declaration templates in the template library, the interface declarations of each computation module are aggregated to generate a model declaration header file that matches the interface of the external caller.

[0074] In this embodiment of the invention, the mapping table from data types to computation modules can be understood as a table recording the correspondence between which computation module processes different data types. The model declaration template can be understood as a general header file template in the template library that reserves interface placeholders and function declaration formats.

[0075] Specifically, when generating the model declaration header file, the system takes as input a mapping table of data types to computation modules contained in the computation description reference data, the core information of the computation description, and declaration templates from the template library. Based on the mapping table, it matches the computation modules corresponding to each data type, aggregates and populates the declaration templates with the class definitions, function prototypes, and other interface declarations of all computation modules, and finally generates a unified model header file. This ensures that the compilation unit implementing internal functions uses a completely consistent interface list with the external caller. Furthermore, interface declarations can be dynamically added or removed based on the chip's computation module architecture, improving the model's interface adaptability and compatibility under different hardware configurations.

[0076] By relying on the mapping table between data types and computation modules within the computation description reference data, and combining it with model declaration templates in the template library to uniformly aggregate the interface declarations of each computation module to generate model declaration header files, the external interfaces of each dispersed computation module can be standardized and integrated. This achieves unified alignment between the internal functional implementation units and the interface definitions of external callers, avoiding compilation errors and call adaptation problems caused by scattered and inconsistent interface declarations. At the same time, generating interface declarations based on standardized templates can reduce the workload of manual writing, reduce human error, ensure interface standardization, and provide a standardized and reliable interface foundation for subsequent code compilation, module calls, and cross-level program interactions, thereby improving the overall code standardization, compatibility, and project maintainability.

[0077] Optionally, based on the above embodiments, generating model implementation source files may include: Based on the operator implementation mapping table, atomic characteristic requirement table, generated header file, and implementation template in the template library from the operation description reference data, the model implementation source file is generated; the main entry point of the model implementation source file adopts the implementation structure of calling the underlying operator by data type branch and by atomic operation category.

[0078] In this embodiment of the invention, the operator implementation mapping table can be specifically understood as a table that records the correspondence between each atomic operation and which segment of underlying operator implementation code.

[0079] Specifically, when generating the model implementation source file, the operator-to-implementation mapping table, atomic characteristic requirement table, various generated header files, and implementation templates in the operation description reference data are used as input. The mapping relationship, hardware requirements, and header file definitions are filled into the placeholder area of ​​the template. The operation logic is constructed according to a unified code implementation structure. The main entry function first performs branch judgment based on the data type of the input to match the corresponding processing logic. Then, based on the atomic operation category, the corresponding underlying operator encapsulation function is called to complete the actual operation. Based on this structure, complete and compilable code content is automatically generated, and finally, a fully functional and structurally standardized model implementation source file is output.

[0080] In addition, the branch hierarchy and operator calling method can be dynamically adjusted according to the chip architecture to improve the model's execution efficiency and adaptability on different hardware platforms.

[0081] By implementing a mapping table based on operators, an atomic characteristic requirement table, and a model that generates header files and implementation templates to generate source files, and by adopting a structured main entry design that branches by data type and calls underlying operators by operation category, the computational logic can be clearly layered and the code structure can be standardized and unified. This ensures accurate connection between upper-level calls and lower-level operators, avoids hard coding and redundant development, improves code readability, maintainability and scalability, and provides an efficient and reliable implementation foundation for subsequent function iterations, hardware adaptation and problem localization.

[0082] Optionally, based on the above embodiments, generating a build description file may include: Based on the build system templates in the template library, generate build rule files that match the template content.

[0083] In this embodiment of the invention, the build system template can be specifically understood as a predefined build script skeleton (such as Makefile or CMake template) in the template library, which may include fixed structures such as library targets, compilation options, and file dependencies.

[0084] Specifically, when generating the build description file, the build system template containing library target definitions, file dependency declarations, and compilation option configurations in the template library is used as input. Based on the project build requirements, the generated macros and type definition header files, model declaration header files, and model implementation source files are respectively filled into the placeholder information positions in the template, such as header file paths, source file paths, compilation dependencies, and linking configurations. This generates a build rule file that matches the template format, ensuring that the generated model declaration header files, type definition header files, and model implementation source files can be uniformly recognized, compiled, and linked by the current project build system.

[0085] By generating corresponding build rule files based on standardized build system templates, the automatically generated model source code can be adapted to the existing build system of the project without the need for manual modification of compilation configuration and linking rules. This avoids problems such as build errors, missing files, and dependency anomalies, ensuring the integration of model code with the overall project, improving code deployment efficiency, reducing integration costs, and enhancing the engineering implementation capability and stability of the entire solution.

[0086] Furthermore, based on the above embodiments, the method for automatically generating atomic test models may further include: Based on the explanatory text in the preset document directory, perform export processing to obtain review archive files and illustrations.

[0087] In this embodiment of the invention, the preset document directory can be understood as: a fixed folder path pre-defined for storing project explanatory documents and notes. The explanatory documents can be understood as: textual documents written in Markdown (markup language) or similar formats, including explanations of the principles of the atomic testing model, interface definitions, and process descriptions. The review and archive files can be understood as: standardized formal documents adapted for technical reviews and project archiving. The illustrations can be understood as: flowcharts, architecture diagrams, data flow diagrams, and other accompanying diagrams generated from the explanatory documents.

[0088] Specifically, the method for automatically generating atomic test models also includes an optional document export step. It only needs to read existing Markdown or other formatted explanatory documents in the preset document directory, automatically perform format conversion and image parsing export processing, and generate formal documents and accompanying process illustrations that can be reviewed by technical reviewers and archived for the long term. This step is independent of the code generation logic, does not participate in or affect the functional logic and compilation correctness of the atomic test model's own source code, and is only used as an auxiliary enhancement step to enrich project deliverables and standardize the review and archiving process.

[0089] By automatically exporting review archive files and accompanying illustrations based on explanatory texts in a preset document directory, standardized delivery documents can be quickly generated without manual reformatting and drawing, saving labor costs for document organization and drawing. At the same time, the well-organized documents and illustrations facilitate R&D and review personnel to quickly understand the architecture and process of the atomic testing model. Moreover, this step does not intervene in the source code generation and logic verification process, and will not interfere with the correctness and stability of the model source code itself. It only improves the form of the deliverables from the delivery level, and enhances the standardization of project archiving and the efficiency of review communication.

[0090] S340, based on the definition header file, interface declaration header file, function implementation source file and build configuration file, performs componentization and hierarchical assembly of the atomic operation model according to the architecture level of the target hardware chip to obtain the atomic test model.

[0091] Furthermore, based on the above embodiments, after obtaining the atomic testing model, it may further include: The atomic test model is loaded into the target hardware chip, and the input transaction data is obtained; By deploying an atomic test model on the target hardware chip, the transaction data is sequentially processed by data type selection, operation type matching, data slicing and shaping, and mapping of atomic operations to hardware operator units. Atomic operations are completed and the atomic operation results are output by calling the corresponding hardware operator unit of the target hardware chip.

[0092] In this embodiment of the invention, transaction data can be specifically understood as: externally input raw business data and incentive data to be used for atomic operations. Data type selection can be specifically understood as: determining the bit width, data type, and other information corresponding to the transaction data, and matching it with a preset macro-defined type specification.

[0093] Operation type matching can be understood as: identifying the atomic operation category corresponding to the transaction data and matching it with a preset operation type macro. Data slicing and integer processing can be understood as: performing preprocessing on the original transaction data, such as segmentation, format regularization, and bit width alignment.

[0094] The mapping from atomic operations to hardware operator units can be understood as: mapping and adapting the atomic operation logic of the software layer to the corresponding hardware operator resources at the chip's underlying layer. Hardware operator units can be specifically understood as: various computational hardware functional units embedded within the target chip, which can be stored in an operator unit library.

[0095] Specifically, after automatically generating the atomic test model, the atomic test model can be deployed and loaded into the target hardware chip. At the same time, it receives externally input transaction data. Relying on the atomic test model deployed on the chip, it sequentially completes the data type identification and selection of the transaction data, atomic operation type matching, data slicing and format shaping preprocessing, and mapping and adapting the software atomic operation logic to the chip hardware operator unit. Then, it calls the corresponding hardware operator unit in the operator unit library built into the target hardware chip to perform atomic operations, and finally outputs compliant and valid atomic operation results.

[0096] In a specific example, the operator unit library is a set of pre-built static basic operators that provide the most basic and lowest-level hardware computing units for model operations. Its significance lies in providing directly callable low-level execution capabilities for higher-level operations.

[0097] The operator unit library is the underlying foundational support, while the atomic operation model and atomic test model are upper-level compilable and runnable components automatically generated based on the operator unit library. The two work together in two phases. In the model code generation phase, the pre-defined operator unit library and template library are called. Based on the operation description reference data, the placeholders in the template library are replaced using the operator names, numbers, interfaces, and calling methods in the operator unit library. This generates macro and type definition header files, model declaration header files, model implementation source files, and construction description files, determining the model's structure and calling logic. In the model execution phase, the atomic test model generated based on the above files performs data type selection, operation type matching, data slicing, and integer processing. Then, it calls the corresponding underlying hardware operators in the operator unit library through operator unit mapping to complete the final atomic operation. The operator unit library is used to define model calling rules in the code generation phase and to provide the model with actual operation execution capabilities in the runtime phase.

[0098] In a specific example, the atomic test model generation process can generate various components required for model building and complete the overall model construction process. During the model's operation and processing of transaction data, the corresponding computational processing logic can be selected and matched according to the data type corresponding to the atomic operation. The computational processing of various atomic operations is completed based on different data types. The configuration number of computational processing logic is determined by the preset atomic characteristic requirement rules. For different atomic operation types, the corresponding computational execution logic can be further matched. The atomic operation process completes the atomic operation processing of the data. First, the original transaction data is split and segmented, bit width aligned, format normalized, and data type adapted preprocessed through data slicing and shaping processes. Then, the various atomic operation logics are mapped to the underlying operator unit library through the operator unit mapping process. The underlying operator units corresponding to signed number addition, unsigned number addition, signed number extremum operation, and logical AND operation are matched and called to complete the complete atomic operation processing process.

[0099] In a specific example, the transaction data required for atomic operations by the model includes key information such as the atomic operation type, data type, and the amount of data involved in the operation. The atomic test model is built using a pipelined automatic generation method, and the overall execution flow is as follows: The atomic test model first determines the data type of the input transaction data. When the data type is determined to meet the preset expectation, it enters the corresponding data type operation model branch for matching. After successful matching, data slicing and shaping are performed sequentially. Then, the data is mapped to the operator unit library, and the processed data is distributed to the corresponding underlying operator unit for operation. Finally, the model operation is completed and the result is output. If any branch in the process does not meet the preset conditions, an error is directly reported and the current process is terminated. After the transaction data is corrected and improved, the complete execution process is restarted until the process verification passes and the atomic operation is completed normally.

[0100] In a specific example, the input transaction data can be adapted to various practical application scenarios. In image processing scenarios, the input transaction data consists of raw image representation data such as image pixel width, pixel operation type, and number of pixel arrays. After the atomic test model sequentially performs data type selection, operation type matching, data slicing and shaping, and operator unit mapping, the output atomic operation results are regularized pixel operation data after image processing, such as pixel filtering, contrast calculation, and pixel extreme value comparison. In large language model inference scenarios, the input transaction data consists of vector representation data such as word vector data type, vector operation category, and number of vector dimensions involved in the operation. After model standardization, the output atomic operation results are intermediate vector operation data for language inference, such as vector accumulation, vector normalization, and vector logic comparison. In industrial measurement and control and chip computing power scheduling scenarios, the input transaction data consists of sensor sampling data such as sampling data width, measurement and control operation type, and sampling point data volume. After model operation processing, the output atomic operation results are industrial measurement and control operation result data such as data calibration, threshold comparison, and numerical filtering, adapting to the underlying atomic operation processing needs of different business scenarios.

[0101] By upgrading the development model from manual source code synchronization to a table-driven automatic generation pipeline based on atomic requirement tables, this solution can seamlessly absorb changes in requirements such as the addition, removal, or modification of data types and operation types. It achieves fully automated generation of model macro definition header files, declaration header files, implementation source files, and build configurations, eliminating the need for manual modification of various header files and computing device logic. This reduces the workload of manual development and maintenance, lowers human and time costs, and eliminates the risk of errors introduced by manual coding. It ensures that the model and requirement tables remain consistent, improving development efficiency, code reliability, and requirement adaptability.

[0102] By loading the generated atomic test model into the target hardware chip, and sequentially performing type selection, operation matching, data regularization, and software / hardware operator mapping on the input transaction data before calling the hardware operator unit to complete the calculation, the test model can be connected to the real hardware. It can automatically complete data preprocessing and software / hardware operation logic adaptation without the need for manual configuration of data format and operator association. This not only improves the automation and efficiency of transaction data operation and processing, but also accurately verifies the execution effectiveness and adaptability of atomic operations under the target chip hardware architecture, ensuring the authenticity and reliability of test results.

[0103] Optionally, based on the above embodiments, performing data slicing and shaping on the transaction data may include: Using the effective data bit width of atomic operations as the granularity, the input transaction data is sliced ​​and then normalized to obtain standard format data.

[0104] In this embodiment of the invention, the effective data bit width for atomic operations can be specifically understood as: the standard data bit width (such as 8 bits, 16 bits, 32 bits) that the underlying hardware operator unit can process, which is the basic granularity of hardware operations. Standard format data can be specifically understood as: the data format that, after slicing and format conversion, can be directly sent to the hardware operator unit for operation.

[0105] Specifically, the core purpose of slicing and reshaping transaction data is to adapt to the operational characteristics of the underlying hardware operator units. Since the basic operator units can only perform calculations in a uniform normalized format with a fixed atomic operation effective data bit width as the granularity, while the actual input transaction data is often long bit width data that exceeds this bit width, it is necessary to first slice the long bit width transaction data with the atomic operation bit width as the granularity, and then perform normalized format conversion on each of the sliced ​​data segments to finally obtain standard format data that fully adapts to the input specifications of the underlying operator units, ensuring that subsequent atomic operations can be executed normally.

[0106] For example, using the effective data bit width of atomic operations as a fixed granularity, the input long-bit-width transaction data is segmented from the high bit to the low bit, splitting it into multiple independent data segments that match the single processing bit width of the hardware operator unit. Then, for each data segment, normalization format processing such as sign bit alignment, data type regularization, and byte order conversion is performed to uniformly adjust it to a bit width, sign format, and storage method that are completely consistent with the input specification of the underlying operator unit, resulting in standard format data that can be directly sent to the operator unit for operation.

[0107] By slicing long-bit-width transaction data into segments with the effective data bit width of atomic operations as the granularity, and performing normalization format conversion on the segmented data, various non-standard, long-bit-width input data in actual business scenarios can be adapted to the fixed processing granularity and operation format of the underlying operator unit. This avoids operation errors or data truncation problems caused by data bit width mismatch or format inconsistency, and realizes the docking between upper-layer transaction data and lower-layer hardware operators. There is no need for manual splitting and format conversion, which improves the automation of data processing and the stability of the operation process, and also lays the data foundation for the subsequent mapping processing of atomic operations to hardware operator units.

[0108] Figure 4 This is a flowchart illustrating an automatic generation system for atomic testing models applicable to embodiments of the present invention, such as... Figure 4 As shown, the atomic characteristic requirement form is used as input, and then passes through the requirement parsing form and the operation description generation form in sequence. The operation description generation form includes data type and bit width, operation type, and the relationship information between type, operation and macro mapping. The operator unit library and template library, together with the above information, participate in the generation of the atomic test model.

[0109] In the atomic testing model, atomic data operation selectors point to UINT (Unsigned Integer), FP (Floating Point), and BF (Brain Floating Point) data operation methods according to data type. The UINT atomic operation selectors within the UINT data operation methods correspond to UINT_ADD (Unsigned Integer Add), UINT_MAX (Unsigned Integer Maximum), and UINT_INC (Unsigned Integer Increment) operations, respectively. Each operation method includes data slicing and integer / operator unit mapping operations. The FP atomic operation selectors within the FP data operation methods correspond to FP_ADD (Floating Point Add) and FP_MAX (Floating Point Maximum) operations, respectively. The BF atomic operation selectors within the BF data operation methods correspond to BF_ADD (Brain Floating Point Add) and BF_INC (Brain Floating Point Increment) operations, respectively. Add (brain floating-point addition) operation, BF_MAX (Brain Floating Point Maximum) operation, etc., the methods at each level work together to realize the automatic generation and operation execution process of the atomic test model.

[0110] Figure 5 This is a schematic diagram illustrating the automatic generation of an atomic testing model applicable to an embodiment of the present invention, such as... Figure 5As shown, the process enters the top-level scheduling stage, inputting parameters such as project configuration, directories, and requirement table paths, and outputting a command list and supporting documentation for the solidified overall pipeline, triggering subsequent steps in sequence; it then enters the requirement parsing stage, inputting atomic requirement tables and outputting structured intermediate data for subsequent table generation; next, it enters the operation description table generation stage, inputting the intermediate data from the previous step and the atomic requirement tables, and outputting a reference database for operation descriptions, including the correspondence between types, bit widths, operations, and macros; finally, it enters the macro and type definition header file generation stage, inputting the operation description reference data and atomic requirement tables, and outputting a header file containing various macro definitions and parameter definitions; and finally, it enters the model declaration header file generation stage. The process begins with the following steps: First, it takes as input the data type and computation module mapping page, operation description reference data, and header file template. The output is a model header file aggregating the declarations of each computation module. Next, it moves to the model implementation source file generation stage. This stage takes as input the operator mapping page, mapping and description worksheets, the generated header files, and implementation templates. The output includes source files containing the main entry point distributed by data type and calling the underlying implementation by operation type. Then, it moves to the build description generation stage. This stage takes as input the template used by the build system and outputs a build rule file consistent with the template. Finally, it moves to the document export stage. This stage takes as input the existing documentation in the document directory and outputs a formatted document and flowchart illustrations, fully covering the automated generation process of the atomic test model from scheduling to delivery.

[0111] Figure 6 This is a schematic diagram of an atomic testing model applicable to an embodiment of the present invention, such as... Figure 6 As shown, the transaction data input to the model is fed into the atomic test model. The atomic test model performs data type judgment. If the data type is determined to be SINT (SignedInteger), it enters the SINT operation type judgment stage. If the operation type is not OP1, it enters the SINT atomic OPn judgment stage. If the match is successful, it is determined to be supported; otherwise, it is not supported and an error is reported and the model exits. If the data type is not SINT, it enters the judgment stage to determine if the data type is N. If the judgment is negative, it is directly not supported and an error is reported and the model exits. If the judgment is positive, it enters the N operation type judgment stage. If the operation type is OP1, it is determined to be supported. If the operation type is not OP1, it enters the N OPn judgment stage. If the match is negative, it is not supported and an error is reported and the model exits. If the match is successful, it is determined to be supported. For transaction data determined to be supported, the operator unit library is called, and the data slicing and integer shaping stage is entered. Then, the operator unit mapping stage is entered, the model operation is executed, and the calculation result is returned. Here, N is a data type other than SINT, and Op1 and OPn represent different atomic operation types. The embodiments of the present invention do not limit the types of data or the hierarchical division of atomic operation types, and can be extended and adapted according to the actual atomic characteristic requirements of the target hardware chip.

[0112] The technical solution of this invention can capture the chip's computational requirements and constraints by obtaining an atomic characteristic requirement table adapted to the target hardware chip and parsing it to obtain structured intermediate data that matches its computing capabilities, and generating computational description reference data based on computational dimension information related to the target hardware chip. The computation description reference data is generated based on the summary mapping of relevant computational dimension information of the target hardware chip. It carries the chip's computational requirements, hardware constraints, and the correlation logic of each computational dimension. Based on this, placeholders in the template library are replaced, ensuring that the replaced template content matches the atomic computation requirements of the target hardware chip and avoiding file failures caused by mismatch between template content and chip characteristics. Calling the preset template library eliminates the need for manual writing of various header files, source files, and build description files from scratch, reducing the workload of manual coding and avoiding syntax errors and logical deviations that are prone to occur during manual writing, thus improving the accuracy of file generation. Through a combination of dynamic filling and compilation configuration, the automatic generation of various files can be achieved, improving file generation efficiency and ensuring consistency and standardization between macros and type definitions, interface declarations, function implementations, and build configurations. This avoids gaps in the connection between files and provides standardized and highly adaptable file support for the subsequent componentization and hierarchical assembly of the atomic computation model. By modularizing and hierarchically assembling the atomic operation model according to the architecture level of the target hardware chip, the generated atomic test model can be adapted to the chip architecture, providing efficient and convenient technical support for chip-level atomic operation testing and improving verification efficiency.

[0113] Example 4 Figure 7 This is a schematic diagram of the structure of an apparatus for automatically generating atomic testing models according to Embodiment 4 of the present invention. Figure 7 As shown, the device includes: a requirements parsing module 710, an association mapping module 720, a file generation module 730, and a hierarchical assembly module 740, wherein: The requirement parsing module 710 is used to obtain and parse the atomic characteristic requirement table that is compatible with the target hardware chip, and obtain the structured intermediate data required for the atomic operation model that matches the computing power of the target hardware chip. The association mapping module 720 is used to associate, summarize and map the computational dimension information related to the target hardware chip based on structured intermediate data and atomic characteristic requirement table, and generate computational description reference data. The file generation module 730 is used to dynamically populate and compile the preset code template resources according to the operation description reference data, and generate definition header files, interface declaration header files, function implementation source files and build configuration files that match the atomic operation model of the target hardware chip. The hierarchical assembly module 740 is used to perform component-based and hierarchical assembly of the atomic operation model according to the architecture hierarchy of the target hardware chip, based on the definition header file, interface declaration header file, function implementation source file and construction configuration file, to obtain the atomic test model.

[0114] The technical solution of this invention, by acquiring an atomic characteristic requirement table adapted to the target hardware chip and parsing it to obtain structured intermediate data matching its computing capabilities, ensures that the generated intermediate data matches the chip hardware characteristics, avoiding model compatibility issues caused by data mismatch. Based on the computing dimension information related to the target hardware chip, it generates computational description reference data, capturing the chip's computational requirements and constraints, providing guidance for subsequent code generation that aligns with the chip's actual needs. By dynamically filling and compiling code template resources with the computational description reference data, it can quickly generate various files adapted to the target hardware chip, reducing the workload of manual code writing and adaptation, and improving model generation efficiency. By modularizing and hierarchically assembling the atomic computation model according to the target hardware chip's architecture, it enables the generated atomic test model to adapt to the chip architecture, ensuring that the model can run stably and efficiently on the target hardware chip after deployment. This also reduces the adaptation, development, and maintenance costs between the model and the chip, improves the accuracy and reliability of atomic testing, and ultimately achieves automated and standardized generation of atomic test models, adapting to the atomic testing needs of different target hardware chips, providing efficient and convenient technical support for chip-level atomic computation testing, and improving verification efficiency.

[0115] Based on the above embodiments, the requirement analysis module 710 is specifically used for: Obtain the atomic characteristic requirement table and read its worksheet content, extracting the atomic operation type, data type, and data bit width information; convert the above information into structured intermediate data in key-value pair form.

[0116] Based on the above embodiments, the association mapping module 720 is specifically used for: Based on structured intermediate data and atomic characteristic requirement tables, the correspondence between data categories, bit widths, operation categories, and macro-level symbols is summarized according to preset rules to generate operation description reference data.

[0117] Based on the above embodiments, the file generation module 730 is specifically used for: The system calls a preset template library, performs placeholder replacement on the template library based on the operation description reference data, and generates macro and type definition header files, model declaration header files, model implementation source files, and construction description files.

[0118] Based on the above embodiments, the file generation module 730 is further configured to: Based on the operation description reference data and the atomic characteristic requirement table, generate macro and type definition header files that include operation class macro enumeration values, data type numerical macros, and user-visible operation type macros.

[0119] Based on the above embodiments, the file generation module 730 is further configured to: Based on the mapping table from data types to computation modules in the computation description reference data, and the model declaration templates in the template library, the interface declarations of each computation module are aggregated to generate a model declaration header file that matches the interface of the external caller.

[0120] Based on the above embodiments, the file generation module 730 is further configured to: Based on the operator implementation mapping table, atomic characteristic requirement table, generated header file, and implementation template in the template library from the operation description reference data, the model implementation source file is generated; the main entry point of the model implementation source file adopts the implementation structure of calling the underlying operator by data type branch and by atomic operation category.

[0121] Based on the above embodiments, the file generation module 730 is further configured to: Based on the build system templates in the template library, generate build rule files that match the template content.

[0122] Furthermore, based on the above embodiments, the apparatus for automatically generating atomic testing models may further include: a description export module, wherein: The documentation export module is used to perform export processing based on the documentation in the preset document directory, resulting in review archive files and illustrations.

[0123] Furthermore, based on the above embodiments, the apparatus for automatically generating atomic test models may further include: a path parsing module, wherein: The path parsing module is used to read the project configuration parameters, directory path, and atomic characteristic requirement table path before obtaining the atomic characteristic requirement table adapted to the target hardware chip. It also parses the atomic characteristic requirement table path to obtain the command list and supporting documentation for the solidified overall pipeline. The command list for the solidified overall pipeline is used to control the process of automatically generating atomic test models. The supporting documentation is used to explain the command list and the overall generation process.

[0124] Furthermore, based on the above embodiments, the apparatus for automatically generating atomic test models may further include: a model loading module and an atomic operation module, wherein: The model loading module is used to load the atomic test model into the target hardware chip after obtaining the atomic test model, and to obtain the input transaction data. The atomic operation module is used to sequentially perform data type selection, operation type matching, data slicing and shaping processing, and mapping of atomic operations to hardware operator units on transaction data through an atomic test model deployed on the target hardware chip. It completes atomic operations and outputs atomic operation results by calling the corresponding hardware operator units of the target hardware chip.

[0125] Based on the above embodiments, the atomic operation module is specifically used for: Using the effective data bit width of atomic operations as the granularity, the input transaction data is sliced ​​and then normalized to obtain standard format data.

[0126] The apparatus for automatically generating atomic test models provided in the embodiments of the present invention can execute the method for automatically generating atomic test models provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0127] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0128] Example 5 Figure 8 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.

[0129] like Figure 8As 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 from storage unit 18 into the RAM 13. 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.

[0130] 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 device, 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.

[0131] 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 method of automatically generating atomic test models, i.e.: Obtain and parse the atomic characteristic requirement table that is compatible with the target hardware chip to obtain the structured intermediate data required for the atomic operation model that matches the computing power of the target hardware chip. Based on structured intermediate data and atomic characteristic requirement tables, the computational dimension information related to the target hardware chip is associated, summarized and mapped to generate computational description reference data. Based on the operation description reference data, the preset code template resources are dynamically populated and compiled and configured to generate definition header files, interface declaration header files, function implementation source files and build configuration files that match the atomic operation model of the target hardware chip; Based on the definition header file, interface declaration header file, function implementation source file, and build configuration file, the atomic operation model is modularized and hierarchically assembled according to the architecture level of the target hardware chip to obtain the atomic test model.

[0132] In some embodiments, the method for automatically generating atomic test models can 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 can 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 method for automatically generating atomic test models described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the method for automatically generating atomic test models by any other suitable means (e.g., by means of firmware).

[0133] 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.

[0134] 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.

[0135] 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.

[0136] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; 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).

[0137] 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.

[0138] 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.

[0139] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0140] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. 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 invention should be included within the scope of protection of this invention.

Claims

1. A method for automatically generating atomic test models, characterized in that, include: Obtain and parse the atomic characteristic requirement table that is compatible with the target hardware chip to obtain the structured intermediate data required for the atomic operation model that matches the computing power of the target hardware chip. Based on structured intermediate data and atomic characteristic requirement tables, the computational dimension information related to the target hardware chip is associated, summarized and mapped to generate computational description reference data. Based on the operation description reference data, the preset code template resources are dynamically populated and compiled and configured to generate definition header files, interface declaration header files, function implementation source files and build configuration files that match the atomic operation model of the target hardware chip; Based on the definition header file, interface declaration header file, function implementation source file, and build configuration file, the atomic operation model is modularized and hierarchically assembled according to the architecture level of the target hardware chip to obtain the atomic test model.

2. The method according to claim 1, characterized in that, Obtain and parse the atomic characteristic requirement table adapted to the target hardware chip to obtain the structured intermediate data required for the atomic operation model that matches the computing power of the target hardware chip, including: Obtain the atomic characteristic requirement table and read its worksheet content, then extract the atomic operation type, data type, and data bit width information; The above information is converted into structured intermediate data in key-value pair format.

3. The method according to claim 1, characterized in that, Based on structured intermediate data and atomic characteristic requirement tables, the computational dimension information related to the target hardware chip is correlated, summarized, and mapped to generate computational description reference data, including: Based on structured intermediate data and atomic characteristic requirement tables, the correspondence between data categories, bit widths, operation categories, and macro-level symbols is summarized according to preset rules to generate operation description reference data.

4. The method according to claim 1, characterized in that, Based on the computational description reference data, the preset code template resources are dynamically populated and compiled to generate definition header files, interface declaration header files, function implementation source files, and build configuration files that match the atomic computation model of the target hardware chip, including: The system calls a preset template library, performs placeholder replacement on the template library based on the operation description reference data, and generates macro and type definition header files, model declaration header files, model implementation source files, and construction description files.

5. The method according to claim 4, characterized in that, Generate macro and type definition header files, including: Based on the operation description reference data and the atomic characteristic requirement table, generate macro and type definition header files that include operation class macro enumeration values, data type numerical macros, and user-visible operation type macros.

6. The method according to claim 4, characterized in that, Generate the model declaration header file, including: Based on the mapping table from data types to computation modules in the computation description reference data, and the model declaration templates in the template library, the interface declarations of each computation module are aggregated to generate a model declaration header file that matches the interface of the external caller.

7. The method according to claim 4, characterized in that, Generate the model implementation source files, including: Based on the operator implementation mapping table, atomic characteristic requirement table, generated header file, and implementation template in the template library from the operation description reference data, the model implementation source file is generated; the main entry point of the model implementation source file adopts the implementation structure of calling the underlying operator by data type branch and by atomic operation category.

8. The method according to claim 4, characterized in that, Generate a build description file, including: Based on the build system templates in the template library, generate build rule files that match the template content.

9. The method according to claim 1, characterized in that, Methods for automatically generating atomic test models also include: Based on the explanatory text in the preset document directory, perform export processing to obtain review archive files and illustrations.

10. The method according to claim 1, characterized in that, Before obtaining the atomic characteristic requirement table adapted to the target hardware chip, the following is also included: The system reads the project configuration parameters, directory path, and atomic characteristic requirement table path, and parses the atomic characteristic requirement table path to obtain the command list and supporting documentation for the solidified overall pipeline. The command list for the solidified overall pipeline is used to control the process of automatically generating atomic test models, while the supporting documentation is used to explain the command list and the overall generation process.

11. The method according to claim 1, characterized in that, After obtaining the atomic testing model, the following is also included: The atomic test model is loaded into the target hardware chip, and the input transaction data is obtained; By deploying an atomic test model on the target hardware chip, the transaction data is sequentially processed by data type selection, operation type matching, data slicing and shaping, and mapping of atomic operations to hardware operator units. Atomic operations are completed and the atomic operation results are output by calling the corresponding hardware operator unit of the target hardware chip.

12. The method according to claim 11, characterized in that, Data slicing and reshaping of transaction data includes: Using the effective data bit width of atomic operations as the granularity, the input transaction data is sliced ​​and then normalized to obtain standard format data.

13. A device for automatically generating atomic test models, characterized in that, include: The requirement parsing module is used to obtain and parse the atomic characteristic requirement table that is compatible with the target hardware chip, and obtain the structured intermediate data required for the atomic operation model that matches the computing power of the target hardware chip. The association mapping module is used to associate, summarize and map computational dimension information related to the target hardware chip based on structured intermediate data and atomic characteristic requirement tables, and generate computational description reference data. The file generation module is used to dynamically populate and compile the preset code template resources according to the operation description reference data, and generate definition header files, interface declaration header files, function implementation source files and build configuration files that match the atomic operation model of the target hardware chip. The hierarchical assembly module is used to perform component-based and hierarchical assembly of the atomic operation model according to the architecture hierarchy of the target hardware chip, based on the definition header file, interface declaration header file, function implementation source file and build configuration file, to obtain the atomic test model.

14. 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 executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the method for automatically generating an atomic test model according to any one of claims 1-12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the method for automatically generating an atomic test model as described in any one of claims 1-12.

16. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method for automatically generating atomic test models according to any one of claims 1-12.

Images