A multi-chip variant-oriented construction pipeline generation method, device and equipment

Abstract

The present application relates to computer technology, disclose a kind of multi-chip variant-oriented construction pipeline generation method, device and equipment, comprising: obtaining chip family description file;Chip family description file is parsed to obtain parsed file and constructs key-value pair tree structure;Based on inheritance declaration field in key-value pair tree structure, depth-first recursive analysis is carried out, the attribute of parent node and child node is merged to obtain full-amount variant configuration list;According to the feature list field in full-amount variant configuration list and the preset feature mapping table, generate target macro definition parameter, and extract kernel configuration file path based on variant definition field to generate kernel configuration loading command;Extract the architecture field in full-amount variant configuration list to match target cross tool chain, combine target macro definition parameter and kernel configuration loading command to fill in preset pipeline template, generate construction pipeline definition file.The present application can improve the efficiency of the construction pipeline automatic generation of multi-chip variant.

Description

Technical Field

[0001] This invention belongs to the field of computer technology, and in particular relates to a method, apparatus and equipment for building pipelines for multiple chip variants. Background Technology

[0002] With the rapid development of the Internet of Things (IoT) and embedded technologies, chip manufacturers and device makers typically launch chip families based on the same infrastructure, targeting different application scenarios. These chip families contain numerous variants, each differing in underlying architecture, storage capacity limitations (such as Flash and RAM size), memory layout, and supported peripheral functionalities. To ensure code quality and delivery efficiency, R&D teams commonly employ continuous integration (CI) / continuous deployment (CD) systems to automate firmware builds.

[0003] In existing firmware automation build solutions, build pipelines are typically implemented by manually writing scripts (such as shell scripts or Makefiles) or directly writing configuration files for specific continuous integration tools (such as Jenkinsfiles or .gitlab-ci.yml). For chip families with numerous variants, existing build pipeline configuration and execution methods suffer from the following technical shortcomings: First, pipeline configurations lack reuse mechanisms, resulting in high maintenance costs and a high susceptibility to errors. Existing technologies mostly employ a "copy-paste" or flattened, exhaustive configuration approach when building different chip variants. Since variants often share many common features (such as the same cross-compiler path, infrastructure, etc.), when a basic attribute needs modification, developers must manually change it one by one from a massive number of pipeline configurations. This approach lacks object-oriented inheritance and overloading mechanisms, leading to a rapid expansion of configuration code with extremely high redundancy, making it highly prone to omissions or errors during firmware version iterations.

[0004] Second, firmware features are heavily coupled with underlying compilation parameters, resulting in low automation. Current technologies often require developers to hard-code numerous macro definitions and kernel configuration file paths directly into the build script when defining a firmware variant. However, there is a complex mapping between product-level "features" and underlying "macro definitions and compilation options." When firmware features are added or removed, manually finding and modifying the corresponding macro definitions is cumbersome and prone to conflicts, making it difficult to automate the conversion from "declarative functional requirements" to "underlying compilation commands."

[0005] Third, the triggering mechanism is crude, resulting in significant waste of computing resources for continuous integration. In multi-variant code repositories, a single code change submitted by a developer—for example, modifying only a peripheral driver file unique to a specific variant—usually triggers a full compilation of all firmware variants across the entire pipeline. Existing technologies lack the ability to track fine-grained dependencies between source code and specific firmware variants, failing to achieve minimized / precise triggering based on the impact of code changes. This leads to lengthy pipeline execution times, greatly wasting computing resources and reducing R&D collaboration efficiency.

[0006] Fourth, firmware artifact management is disorganized, making automated release difficult. Existing build scripts often pile up the compiled firmware artifacts in a single directory, lacking a unified naming convention and metadata management. In scenarios where multiple variants are built simultaneously, it is difficult to intuitively distinguish the chip family, specific functions, and code versions by artifact names or tags, which brings difficulties to subsequent automated testing, archiving, and over-the-air firmware download and release.

[0007] In summary, existing technologies result in low efficiency in the automatic generation of multi-chip variant build pipelines and high maintenance costs for multi-chip variant builds. Summary of the Invention

[0008] This invention provides a method, apparatus, and device for generating a build pipeline for multiple chip variants, which can improve the efficiency of automatic generation of build pipelines for multiple chip variants.

[0009] To achieve the above objectives, the present invention provides a method for generating a construction pipeline for multi-chip variants, comprising: Obtain the chip family description file, which contains a base class definition field and a variant definition field. The variant definition field contains an inheritance declaration field, an architecture field, and a feature list field. The chip family description file is parsed to obtain a parsed file, and a key-value pair tree structure is constructed based on the parsed file; Based on the inheritance declaration fields in the key-value tree structure, a depth-first recursive parsing is performed, tracing upwards along the inheritance chain to the preset root class, and merging the attributes of the parent node and child node to obtain a full variant configuration list, which does not contain inheritance reference data; Based on the feature list field in the full variant configuration list and the preset feature mapping table, the target macro definition parameters are generated, and the kernel configuration file path is extracted based on the variant definition field to generate the kernel configuration loading command. Extract the architecture fields from the full variant configuration list to match the target cross-toolchain, combine the target macro definition parameters and kernel configuration loading commands to populate the preset pipeline template, and generate the build pipeline definition file.

[0010] To address the aforementioned problems, the present invention also provides a build pipeline generation apparatus for multi-chip variants, the apparatus comprising: The file parsing module is used to obtain a chip family description file, which contains a base class definition field and a variant definition field. The variant definition field contains an inheritance declaration field, an architecture field, and a feature list field. The chip family description file is parsed to obtain a parsed file, and a key-value pair tree structure is constructed based on the parsed file. The configuration derivation module is used to perform depth-first recursive parsing of inheritance declaration fields in the tree structure based on key values, trace up the inheritance chain to the preset root class, and merge the attributes of parent nodes and child nodes to obtain a full variant configuration list, which does not contain inheritance reference data. The pipeline generation module is used to generate target macro definition parameters based on the feature list fields in the full variant configuration list and the preset feature mapping table, and to extract the kernel configuration file path based on the variant definition fields to generate the kernel configuration loading command; it also extracts the architecture fields in the full variant configuration list to match the target cross-toolchain, and combines the target macro definition parameters and the kernel configuration loading command to fill the preset pipeline template to generate the build pipeline definition file.

[0011] To address the above problems, the present invention also provides an electronic device, 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 that can be executed by the at least one processor, which enables the at least one processor to perform the above-described method for building a pipeline for multi-chip variants.

[0012] To address the aforementioned problems, the present invention also provides a computer-readable storage medium storing at least one computer program, which is executed by a processor in an electronic device to implement the aforementioned method for building a pipeline for multiple chip variants.

[0013] This invention obtains a chip family description file, which includes a base class definition field and a variant definition field. The variant definition field includes an inheritance declaration field, an architecture field, and a feature list field. This enables the objectification and structuring of firmware variant configuration. By introducing the base class definition field and the variant definition field, the originally unordered chip family description file gains a foundation of topological relationships. Furthermore, parsing the chip family description file yields a parsed file, and constructing a key-value pair tree structure based on the parsed file transforms the plain text description file into a tree-like data structure that is easily traversed and computed by a computer, establishing the parent-child relationship between different chip configuration nodes. Moreover, based on the inheritance declaration field in the key-value pair tree structure, a depth-first recursive parsing is performed, tracing upwards along the inheritance chain to a preset root base class, merging the attributes of parent and child nodes to obtain the full variant configuration. The full variant configuration list does not contain inherited reference data, enabling automated inheritance of configuration parameters and attribute overloading. This eliminates the need to repeatedly write the same infrastructure or toolchain paths, reducing long-term maintenance costs. Furthermore, based on the feature list fields in the full variant configuration list and a preset feature mapping table, target macro definition parameters are generated. The kernel configuration file path is extracted based on the variant definition fields to generate kernel configuration loading commands. This enables automatic translation from declarative business requirements to executable compilation instructions, avoiding conflicts caused by manual hard-coding of macro definitions and improving automation. Finally, the architecture fields in the full variant configuration list are extracted to match the target cross-toolchain. Combined with the target macro definition parameters and kernel configuration loading commands, a preset pipeline template is filled to generate a build pipeline definition file, improving the efficiency of automatic build pipeline generation for multi-chip variants. Attached Figure Description

[0014] Figure 1 This is a flowchart illustrating a method for generating a construction pipeline for multiple chip variants according to an embodiment of the present invention. Figure 2 A functional block diagram of a build pipeline generation device for multiple chip variants provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device that implements the method for building a pipeline for multiple chip variants, as provided in an embodiment of the present invention.

[0015] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0016] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0017] This application provides a method for generating a build pipeline for multiple chip variants. The execution entity of this method includes, but is not limited to, at least one electronic device that can be configured to execute the method provided in this application, such as a server or a terminal. In other words, the method for generating a build pipeline for multiple chip variants can be executed by software or hardware installed on a terminal device or a server device, and the software can be a blockchain platform. The server includes, but is not limited to, a single server, a server cluster, a cloud server, or a cluster of cloud servers. The server can be a standalone server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0018] Reference Figure 1 The diagram shown is a flowchart illustrating a method for generating a construction pipeline for multiple chip variants according to an embodiment of the present invention. In this embodiment, the method for generating a construction pipeline for multiple chip variants includes: S1. Obtain the chip family description file, which contains a base class definition field and a variant definition field. The variant definition field contains an inheritance declaration field, an architecture field, and a feature list field.

[0019] Understandably, a chip family description file is a structured text file constructed using declarative syntax to uniformly represent multiple firmware variants and their hardware and software configuration attributes within the same chip family. Its core logic lies in transforming the traditionally manually written pipeline process instructions into a declarative description of the inheritance model and variant characteristics of the entire chip family, so that the engine can parse and map the relevant configurations.

[0020] Understandably, the base class definition field refers to the configuration data structure used in the description file to declare the common underlying characteristics of the series of chips. It encapsulates the common underlying architecture, common software modules and default build parameters shared by various sub-chip variants. It serves as the starting root node in the entire inheritance tree, allowing the next level or the last level sub-variant to automatically extend and reuse it.

[0021] Understandably, the variant definition field refers to a fine-grained description data block corresponding to a specific firmware target image to be compiled. It defines personalized configuration parameters belonging to a specific chip model, including specific values ​​of the firmware in terms of physical resource dimensions such as code region division and data region limitation, as well as unique peripheral or application configurations that distinguish this specific chip model from other variants.

[0022] Understandably, the inheritance declaration field refers to the mapping identifier explicitly declared within the variant definition field, which is used to accurately indicate the hierarchical tracing relationship between the currently processed child variant and the parent node or the base class definition field, thereby guiding the parsing system to trace from bottom to top along the specified hierarchical association chain and realize the recursive merging of multi-level configuration attributes.

[0023] Understandably, the architecture field refers to enumerated scalar data representing the core instruction set architecture type of the target chip. Its function is to serve as a keyword to query the pre-set matching rule library during the pipeline automatic derivation process, so as to automatically bind the cross-compiler prefix and related platform compilation options corresponding to the target firmware.

[0024] Understandably, the feature list field refers to a data set declared in the form of an array or list, representing the peripheral modules or functional features supported by the target firmware variant. The feature list field is subject to the set operation rules of merging and deduplication during the inheritance expansion stage, and in subsequent stages, it serves as an association source, automatically expanding and injecting the switch symbols and underlying compilation environment macro parameters that the target firmware kernel configuration system depends on through the feature-macro mapping relationship.

[0025] Specifically, before obtaining the chip family description file, which includes base class definition fields and variant definition fields, a product archiving management step is also included: The firmware artifact file name is generated based on the variant definition field. The firmware artifact file name is composed of the chip family name, variant name, version submission identifier and build timestamp. Based on the specific function names contained in the feature list fields, attach corresponding feature tag metadata to the firmware artifact; Generate a separate archive subdirectory based on the variant name, and write the output archive instruction containing the archive subdirectory in the build pipeline definition file.

[0026] Understandably, feature tag metadata refers to a structured descriptive attribute dataset that is bound to the final binary firmware entity generated by the underlying compilation and is independent of the executable code of the firmware body. Feature tag metadata integrates the semantics of the feature list fields obtained from the previous parsing and transforms them into a system-level index dimension that can be natively parsed by the continuous integration platform or archiving system.

[0027] For example, before obtaining the chip family description file, which includes base class definition fields and variant definition fields, a product archiving management step is included, which can be implemented using the following steps: Step 1, Naming Conventions: Deliverable filenames follow the format {chip family name}_{variant name}_{Git short commit hash}_{build timestamp}.bin. For example, the deliverable for the PG3 variant committed with a1b2c3d is named pgfamily_pg3_a1b2c3d_20260714.bin. This naming convention is automatically written into the post-build processing steps by the engine during the build pipeline generation phase. Git is a distributed version control system used to track historical changes to the source code.

[0028] Step 2, Classification and Tagging: The engine automatically tags variant artifacts based on their features. For example, variant artifacts containing the BLE feature are automatically tagged with the feature-BLE tag, and those containing the security module SE feature are tagged with the feature-SE tag. These tags are represented as Jenkins build metadata in the continuous integration (CI) system, which can be retrieved and filtered through the CI interface. BLE stands for Bluetooth Low Energy, a short-range wireless communication technology standard designed for low power consumption and extremely common in IoT devices; here, it indicates that the variant has Bluetooth communication capabilities. Jenkins is a widely used open-source automation server software and a core tool for implementing CI / CD (Continuous Integration / Continuous Deployment), capable of scheduling and executing build, test, and deployment tasks.

[0029] Step 3, Archive Path: The engine generates an independent archive subdirectory for each variant, with the path format being artifacts / {variant name} / {date} / {build number} / . All variant artifacts are archived uniformly to the Artifact repository of the continuous integration (CI) system. The engine automatically writes the archiveArtifacts directive in the post.success block of the Pipeline DSL, specifying the artifact path pattern for that variant (e.g., ...). This ensures automatic archiving after a successful build. DSL (Domain Specific Language) refers to a computer language specifically designed for a particular purpose. In this embodiment, "Pipeline DSL" specifically refers to the specialized syntax used by Jenkins to write pipeline configuration scripts. "post" is a post-processing block, a key field in the Jenkins pipeline syntax, used to define the final operations to be performed after the core build phase (compilation), such as sending emails, cleaning up the environment, and archiving files. The "archiveArtifacts" directive is an archive artifact directive, a built-in core command in the Jenkins pipeline. Its function is to tell the server to permanently save the specified compiled result files (such as .bin files) to the server's secure storage area, preventing them from being deleted during build workspace cleanup. "success" is a success status condition, usually a conditional trigger nested within the "post" block, meaning that the inner wrapper instruction is executed only if all build steps are successful and no errors occur.

[0030] S2. Parse the chip family description file to obtain a parsed file, and construct a key-value pair tree structure based on the parsed file.

[0031] Understandably, the parsed file refers to the intermediate serialized data carrier generated by the pipeline's automatic generation engine after performing lexical analysis and syntax verification on the chip family description file in its original text format. At the physical level, the parsed file strips away formatting characters and non-executable comment information from the original text, extracting and solidifying the original declaration semantics of each configuration node. This serves as transitional data for the system's conversion from text stream to memory objects, thereby ensuring the security of subsequent data extraction processes and the legality of the configuration format.

[0032] Understandably, a key-value tree structure refers to a multi-branch hierarchical data retrieval model generated by loading the parsed file into memory. Each node in the key-value tree structure is composed of a "key" used to represent the configuration item identifier and the specific "value" contained in that configuration item. Depending on the indentation or nesting logic of the parsed file, the "value" can be dynamically represented as a single scalar data, an ordered list of features, or a nested key-value pair object that further contains child nodes.

[0033] Understandably, the key-value tree structure in this embodiment of the invention intuitively and accurately reconstructs the subordinate mapping relationship between the chip base class, each level of variants, and the underlying compilation parameters in memory, providing a structured and easily addressable basic operation view for the subsequent engine to perform depth-first traversal based on inheritance chains and recursive merging operations of attributes.

[0034] For example, the chip family description file is parsed to obtain a parsed file, and a key-value pair tree structure is constructed based on the parsed file, which is implemented using the following steps: Step 1: First, load the chip family description file (YAML text) into an in-memory key-value tree structure (using a standard YAML parsing library, such as Python's PyYAML or C++'s yaml-cpp). Then, perform format validation on each field—checking if required fields exist (e.g., arch, flash_size, features, memory_layout, kconfig), if field values ​​are valid (e.g., arch must be one of the predefined architecture enumeration values), and if extends references point to a defined base class. If validation fails, output an error report and terminate the process.

[0035] Step 2: The Inheritance Expander parser outputs the original list of variant definitions containing the `extends` reference. The Inheritance Expander performs a depth-first recursive parsing for each variant: starting from the current variant, it traces upwards along the `extends` chain until it reaches the root class `_base`, and then merges the properties of each level in the inheritance chain in the order of "from root to leaf" to obtain a key-value tree structure.

[0036] In this embodiment of the invention, YAML (YAML Ain't a Markup Language) refers to a highly readable format used to express data serialization. Its syntax is similar to other high-level languages, and it can easily express data formats such as lists, hash tables, and scalars. YAML's use of whitespace indentation and its heavy reliance on appearance make it particularly suitable for expressing or editing data structures, various configuration files, demodulation and debugging content, and document outlines (e.g., many email header formats are very similar to YAML). Although YAML is more suitable for expressing hierarchical data structures, it also has sophisticated syntax for representing relational data.

[0037] S3. Based on the key-value pair, perform a depth-first recursive parsing of the inheritance declaration fields in the tree structure, trace upwards along the inheritance chain to the preset root class, and merge the attributes of the parent node and the child node to obtain a full variant configuration list. The full variant configuration list does not contain inheritance reference data.

[0038] Understandably, an inheritance chain refers to a unidirectional topological path in the chip family configuration data model (i.e., a key-value tree structure), in which each configuration node (chip variant or base class) is logically linked together sequentially through inheritance declaration fields, and has a clear hierarchical dependency relationship.

[0039] Understandably, the preset root class refers to the core common parent node object at the highest level in the key-value pair tree structure. It pre-defines the lowest-level global default configuration and general compilation rules that all derivative products in the current chip family must follow. When performing depth-first recursive parsing, the preset root class serves as the absolute endpoint of the subordinate association tracing operation, ensuring that the configuration inheritance expansion process has clear boundaries.

[0040] Understandably, the full variant configuration list refers to the complete state dataset output in system memory after recursively covering and combining attributes along the inheritance tree, containing all necessary build parameters for each target firmware. In the full variant configuration list, each specific variant node has losslessly integrated all common characteristics absorbed from its parent nodes along the inheritance chain, as well as its own declared unique attributes, forming an independent and logically self-consistent complete configuration entity. This provides a complete parameter map for subsequent direct rendering of the build pipeline template without requiring secondary assembly.

[0041] Understandably, inherited reference data refers to pointer-type association fields used in the original configuration file and initial tree structure to declare the parent-child node dependency mapping relationship. The fact that the full variant configuration list does not contain inherited reference data means that after the engine's dimensionality reduction and expansion processing, all hierarchical dependencies have been replaced by substantial attribute value merging operations. Each variant object is freed from the original nested network of relationships, which improves the efficiency of data reading and addressing in the subsequent compilation and deduction stages.

[0042] Specifically, the attributes of the parent and child nodes are merged to obtain a full list of variant configurations, including: Identify the data type of the attribute to be merged; When the data type is a scalar type, the attribute value explicitly declared in the child node overrides the attribute value with the same name in the parent node; When the data type is a list, the list data of the parent node is converted into the first set, the list data of the child node is converted into the second set, the first set and the second set are combined, and the result is used as the target attribute value after merging.

[0043] Furthermore, the attributes corresponding to the scalar type include architecture type, flash memory capacity limit, memory capacity region division, compiler path, and memory layout linker script path; The attributes corresponding to the list type include a set of firmware feature modules.

[0044] For example, based on key-value pairs, the inheritance declaration fields in the tree structure are parsed using a depth-first recursive approach, tracing upwards along the inheritance chain to the preset root class. The attributes of parent and child nodes are merged to obtain a full variant configuration list. The merging rules for parent and child node attributes are as follows: Rule 1: Scalar Attributes – Child Overrides Parent: For scalar type attributes (such as arch, flash_size, ram_size, toolchain, memory_layout, kconfig, build_system, etc.), the value explicitly declared in the child variant directly overrides the value of the parent attribute with the same name. For example, if the base class _base declares arch:riscv32, and the variant PG4 declares arch:riscv64, then the final arch value of PG4 will be riscv64. If a child variant does not declare a scalar property, it inherits the value from its parent; riscv32 / riscv64 are the 32-bit / 64-bit versions of the RISC-V architecture, which is an open-source reduced instruction set architecture; riscv32-unknown-elf- is the standard prefix naming convention for bare-metal (without an operating system) RISC-V 32-bit cross-compilation toolchains; -march=rv32 imac (usually rv32imac) is the target machine architecture compilation parameter, informing the compiler to generate code containing a specific instruction set: rv32 represents 32-bit, i represents basic integer instructions, m represents hardware multiplication and division, a represents atomic operations, and c represents compressed instructions; -mabi=ilp32 is the Machine Application Binary Interface parameter, ilp32 specifies that int (integer), long (long integer), and pointer in C language all occupy a 32-bit (4-byte) data width; -T is a parameter specified by the linker script in the toolchain GCC (GNU). The Compiler Collection (a core component of the GNU compiler suite, responsible for compiling C / C++ high-level language source code into assembly language) is used to explicitly pass the path of a custom linker script to the linker; CROSS_COMPILE is a cross-compilation environment variable that, when using the Make system, injects a prefix for the compiler name (e.g., injecting riscv32-unknown-elf-, which the Make system will automatically append to with gcc / ld, etc., to execute the final command); the Make system is a classic automated build tool that drives the compiler execution by reading the dependency rules in the Makefile; the Makefile is a configuration script file that the Make tool depends on, internally defining the compilation order, dependencies, and specific compilation commands between source code files.

[0045] Rule 2: List Properties – Set Union Operation: For list-type properties like `features`, use the set union operation (Union) instead of overriding or appending. Specifically: First, convert the parent's `features` list into a set, then convert the child variant's declared `features` list into a set, and finally take the union of the two sets as the final value. For example, if PG4 inherits from `_base` (assuming `_base`'s `features` field is empty or does not exist), and PG4 declares `features:[hplc,dma,gpio,ble]`, then PG4's final `features` is `{hplc,dma,gpio,ble}`; if PG5 inherits from PG4 and declares `features:[hplc,dma,gpio,ble,se]`, then PG5's final `features` is `{hplc,dma,gpio,ble,se}`. The design intent of using set union operations instead of simple overriding is to ensure that sub-variants do not lose functionality due to the omission of parent features, while allowing sub-variants to add new features. HPLC stands for High-Speed ​​Power Line Communication, a communication technology that utilizes existing power lines to transmit data and is widely used in the Internet of Things (IoT) field (such as smart grids and smart homes). DMA stands for Direct Memory Access, a technology module that allows hardware peripherals to directly read and write data to memory without full CPU intervention, which can significantly reduce CPU load. GPIO stands for General-Purpose Input / Output, the most basic programmable digital pin on the chip, used to control high and low levels or read external signals.

[0046] Rule 3: Object Attributes - Recursive Merging: For nested object type attributes (such as sub-configurations under memory_layout), a recursive merging strategy is adopted: apply Rule 1 and Rule 2 above to each sub-field of the object.

[0047] Understandably, in this embodiment of the invention, the data type of `arch` is an enumerated string. The pipeline engine can select the corresponding cross-compiler prefix (such as `riscv32-unknown-elf-`) and compilation parameters (such as `-march=rv32 imac-mabi=ilp32`) from the architecture-toolchain mapping table based on this field; the data type of `flash_size` is a string (numerical value + unit). The pipeline engine can pass this value to the linker script to set the starting address and size limit of the `.text` segment (code segment) and the `.rodata` segment (read-only data segment); and simultaneously check whether the firmware image exceeds the Flash capacity during the artifact verification stage; the data type of `ram_size` is a string (numerical value + unit). The pipeline engine can pass this value to the linker script to set the memory region division of the `.data` segment (initialized global variables) and the `.bss` segment (uninitialized global variables); toolchain... The data type of `n` is a string. The pipeline engine can use this to construct the complete compiler path (e.g., `{toolchain}-gcc`), assembler path (`{toolchain}-as`), linker path (`{toolchain}-ld`), and binary tool path (`{toolchain}-objcopy`), and set the `CROSS_COMPILE` environment variable. The data type of `memory_layout` is a string (filename). The pipeline engine can map this filename to the linker script path in the file system, and pass it to the linker in the compilation command via the `-T` parameter (e.g., `-T...`). The linker uses `kl3_memory.ld` to locate each segment to the chip's physical memory address; `kconfig` is a string (filename) and the pipeline engine can automatically insert `make kl3_defconfig` or an equivalent Kconfig configuration loading command during the build step, allowing the compiler to read the kernel configuration defaults for that variant before compilation; `build_system` is an enumerated string and the pipeline engine can use it to select different build command templates and artifact path rules: the `make` system uses the `make -j{N}CROSS_COMPILE=xxx` command; the `cmake` system first executes `cmake -DCMAKE_TOOLCHAIN_FILE=xxx`.`cmake` generates a Makefile, then `make` is executed; the data type of `features` is a list (string array), which the pipeline engine uses to select the corresponding OS adaptation layer source file directory and compilation parameters; PG5 refers to an exemplary identifier used in this embodiment to characterize a parent-level derived chip variant or a mid-level basic configuration chip; PG4 refers to an exemplary identifier used in this embodiment to characterize a child-level incremental derived chip variant or a customized extended function chip; `cmake` is the script file extension for the CMake system, and in this document refers to an environment description file that encapsulates the cross-compiler path and target platform architecture settings.

[0048] S4. Based on the feature list field in the full variant configuration list and the preset feature mapping table, generate the target macro definition parameters, and extract the kernel configuration file path based on the variant definition field to generate the kernel configuration loading command.

[0049] Understandably, the preset feature mapping table refers to the set of rules for the association and comparison dictionary that is pre-maintained within the build engine. It establishes a deterministic translation mapping relationship from the upper-level abstract functional feature strings to the lower-level micro-build parameters.

[0050] Understandably, the kernel configuration file path refers to the absolute or relative hierarchical location address of the default kernel configuration data entity for a specific firmware variant within the project file system. Based on the extracted kernel configuration file path, the build engine and related toolchain can accurately address and read the default configuration text covering the operating system adaptation layer, hardware peripheral driver enable status, and system runtime baseline parameters within the workspace directory tree, using it as the basic data base for initializing cross-compilation operations.

[0051] Understandably, the kernel configuration loading command refers to the system-level executable script interaction instructions that are automatically assembled by the pipeline engine and injected into the specific build steps. The execution time of this kernel configuration loading command is before the formal cross-compilation task is issued. Its purpose is to call the underlying target build system to read the previously located missing configuration files, thereby forcibly loading and applying the declared relevant hardware function switches and kernel feature configurations in the current operating context memory.

[0052] Specifically, based on the feature list field in the full variant configuration list and the preset feature mapping table, target macro definition parameters are generated, and the kernel configuration file path is extracted based on the variant definition field to generate the kernel configuration loading command, including: Iterate through each feature name in the feature list field, retrieve the corresponding configuration symbol and macro definition by querying the pre-maintained feature name and macro definition lookup table, and append the configuration symbol and macro definition to the compilation parameter set of the corresponding variant to obtain the target macro definition parameter; The configuration declaration field in the variant definition field is mapped to the target kernel configuration file path in the file system, and the target kernel configuration file path is inserted into the corresponding kernel configuration file loading instruction before the preset multi-chip variant build step command to obtain the kernel configuration loading command.

[0053] Understandably, the macro definition lookup table refers to a specific associative mapping dictionary structure built into the pipeline build engine. This macro definition lookup table solidifies the conversion correspondence between abstract-level business feature identifiers and the kernel system switches and compiler environment control variables required in the underlying preprocessing stage. By retrieving this macro definition lookup table, the system can seamlessly translate the declared macro-functional modules into a set of basic condition parameters that drive the selective compilation of the source code, thereby achieving precise docking between declarative feature expansion instructions and automated pruning actions of the underlying code logic.

[0054] Understandably, the kernel configuration file loading instruction refers to a system-level control password that is dynamically concatenated by the pipeline generation engine for a specific build task and pre-issued to the continuous integration execution node. Its mechanism is to drive the underlying engineering build system to read and parse the default kernel configuration text specified by the target path, thereby loading the preset hardware driver state, operating system kernel parameters, and resource allocation rules into the context environment of the current build workspace, ensuring that the subsequent cross-compilation process can correctly generate the corresponding firmware object based on the matching base configuration items.

[0055] S5. Extract the architecture field from the full variant configuration list to match the target cross-toolchain, combine the target macro definition parameters and kernel configuration loading commands to fill the preset pipeline template, and generate the build pipeline definition file.

[0056] Understandably, a target cross-toolchain refers to a collection of executable programs used to translate underlying source code into machine code adapted to heterogeneous chip instruction set architectures. It encompasses compilers, linkers, and system dependency libraries that precisely match the architecture fields obtained from the current parsing. Understandably, the preset pipeline template refers to a pre-defined, built-in description text of the automated build task skeleton within the platform. This text structure pre-defined pipeline template solidifies the standardized continuous integration lifecycle execution flow, including code retrieval, environment initialization, compilation and building, and even artifact archiving. At the same time, it retains placeholder identifiers for dynamically injecting variant dependencies, environment control variables, and customized script instructions, thus serving as a general basic orchestration framework that carries the specific business logic of each independent variant.

[0057] Understandably, the pipeline definition file refers to the instantiated task configuration file output by the pipeline build engine after performing dynamic replacement of placeholders and automatic parameter filling, which can be natively parsed and directly executed by the underlying continuous integration scheduler. This configuration file integrates the toolchain environment location information required for specific variants, the set of global compilation macro definitions, and the pre-kernel loading script instructions, providing the platform execution cluster with clear task orchestration order, resource allocation strategies, and build environment isolation guidelines.

[0058] Specifically, after generating the build pipeline definition file, a minimal build triggering step based on code changes is also included: Parse the dependency description file output by the code compilation and build the dependency mapping relationship between the source code file and the target firmware variant; When changes to the codebase are detected, retrieve the list of changed files; Query the list of change files in the dependency mapping relationship, extract the set of affected associated variants, and trigger only the single variant build step corresponding to the set of associated variants in the build pipeline definition file.

[0059] Understandably, minimized build triggering refers to a task-oriented scheduling and control mechanism that optimizes system computing resources and shortens the continuous integration feedback cycle. This mechanism abandons the inherent logic of blindly launching full-scale derivative chip compilation tasks when code repository content changes. Instead, it relies on the dependency mapping network between source files built from previous compilation actions and target firmware configurations to trace the changed source code. It only issues recompilation instructions to specific affected derivative branches, thereby avoiding redundant build actions with no actual business benefit and significantly improving the computing power utilization efficiency of the continuous integration platform.

[0060] Understandably, a single-variant build step refers to an isolated executable logic unit, embedded in the build pipeline definition text and specifically designed for a particular chip-derived branch. This isolated executable logic unit encapsulates the complete operational chain of environment loading, cross-compilation, and artifact output required to match the specific branch configuration, and maintains physical and logical boundary isolation from parallel bypass branch tasks at runtime. With this fine-grained task decomposition architecture, the continuous integration engine can respond to the aforementioned on-demand scheduling instructions, precisely activating the execution flow of the target branch affected by changes, without interfering with the remaining stable firmware configurations.

[0061] Furthermore, the dependency description file output by the compiled code is parsed to construct the dependency mapping relationship between the source code file and the target firmware variant, including: After the full build task is completed, iterate through the dependency description files in the build directory corresponding to each variant; Extract the header file paths and corresponding source code file lists recorded in the dependency description file; The extracted list of source code files is associated with the identification information of the current variant, and the association is stored in the dependency mapping relationship.

[0062] This invention obtains a chip family description file, which includes a base class definition field and a variant definition field. The variant definition field includes an inheritance declaration field, an architecture field, and a feature list field, enabling the objectification and structuring of firmware variant configurations. By introducing the base class definition field and the variant definition field, the originally unordered chip family description file gains a foundation of topological relationships. Furthermore, parsing the chip family description file yields a parsed file, and constructing a key-value pair tree structure based on the parsed file transforms the plain text description file into a tree-like data structure that is easily traversed and computed by a computer, establishing the parent-child relationship between different chip configuration nodes. Moreover, based on the inheritance declaration field in the key-value pair tree structure, a depth-first recursive parsing is performed, tracing upwards along the inheritance chain to the preset root base class, merging the attributes of parent and child nodes to obtain the full set of variants. The configuration list, which does not contain inherited reference data, enables automated inheritance of configuration parameters and attribute overloading, eliminating the need to repeatedly write the same infrastructure or toolchain paths and reducing long-term maintenance costs. Furthermore, based on the feature list fields in the full variant configuration list and a preset feature mapping table, target macro definition parameters are generated. The kernel configuration file path is extracted based on the variant definition fields to generate kernel configuration loading commands, enabling automatic translation from declarative business requirements to executable compilation instructions. This avoids conflicts caused by manually hard-coding macro definitions and improves automation. Finally, the architecture fields in the full variant configuration list are extracted to match the target cross-toolchain. Combined with the target macro definition parameters and kernel configuration loading commands, a preset pipeline template is filled to generate a build pipeline definition file, improving the efficiency of automatic build pipeline generation for multi-chip variants.

[0063] like Figure 2 The diagram shown is a functional block diagram of a construction pipeline generation device for multi-chip variants provided in an embodiment of the present invention.

[0064] The build pipeline generation apparatus 100 for multi-chip variants described in this invention can be installed in an electronic device. Depending on the functions implemented, the build pipeline generation apparatus 100 for multi-chip variants may include a file parsing module 101, a configuration derivation module 102, and a pipeline generation module 103.

[0065] The module described in this invention can also be called a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and can perform a fixed function, and are stored in the memory of the electronic device.

[0066] In this embodiment, the functions of each module / unit are as follows: The file parsing module 101 is used to obtain a chip family description file, which includes a base class definition field and a variant definition field. The variant definition field includes an inheritance declaration field, an architecture field, and a feature list field. The chip family description file is parsed to obtain a parsed file, and a key-value pair tree structure is constructed based on the parsed file.

[0067] The configuration derivation module 102 is used to perform depth-first recursive parsing of the inheritance declaration fields in the key-value tree structure, trace up the inheritance chain to the preset root class, and merge the attributes of the parent node and the child node to obtain a full variant configuration list, which does not contain inheritance reference data.

[0068] The pipeline generation module 103 is used to generate target macro definition parameters based on the feature list fields in the full variant configuration list and the preset feature mapping table, and extract the kernel configuration file path based on the variant definition fields to generate the kernel configuration loading command; extract the architecture fields in the full variant configuration list to match the target cross toolchain, and combine the target macro definition parameters and the kernel configuration loading command to fill the preset pipeline template to generate the build pipeline definition file.

[0069] like Figure 3 The diagram shown is a structural schematic of an electronic device that implements a construction pipeline generation method for multi-chip variants, according to an embodiment of the present invention.

[0070] The electronic device may include a processor 10, a memory 11, a communication bus 12, and a communication interface 13. It may also include a computer program stored in the memory 11 and executable on the processor 10, such as a pipeline generation method program for multi-chip variants.

[0071] In some embodiments, the processor 10 may be composed of integrated circuits, such as a single packaged integrated circuit or multiple integrated circuits with the same or different functions, including combinations of one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and various control chips. The processor 10 is the control unit of the electronic device, connecting various components of the entire electronic device through various interfaces and lines. It executes programs or modules stored in the memory 11 (e.g., executing a pipeline generation method program for multi-chip variants) and calls data stored in the memory 11 to perform various functions of the electronic device and process data.

[0072] The memory 11 includes at least one type of readable storage medium, including flash memory, portable hard drive, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 11 can be an internal storage unit of an electronic device, such as a portable hard drive. In other embodiments, the memory 11 can be an external storage device of the electronic device, such as a plug-in portable hard drive, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc. Furthermore, the memory 11 can include both internal and external storage units of the electronic device. The memory 11 can be used not only to store application software and various types of data installed on the electronic device, such as the code of a pipeline generation method program for multi-chip variants, but also to temporarily store data that has been output or will be output.

[0073] The communication bus 12 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into an address bus, a data bus, a control bus, etc. The bus is configured to enable communication between the memory 11 and at least one processor 10, etc.

[0074] The communication interface 13 is used for communication between the aforementioned electronic device and other devices, including a network interface and a user interface. Optionally, the network interface may include a wired interface and / or a wireless interface (such as a Wi-Fi interface, Bluetooth interface, etc.), typically used to establish communication connections between the electronic device and other electronic devices. The user interface may be a display, an input unit (such as a keyboard), or optionally, a standard wired or wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. The display may also be appropriately referred to as a screen or display unit, used to display information processed in the electronic device and to display a visual user interface.

[0075] Figure 3 Only electronic devices with components are shown; it will be understood by those skilled in the art that... Figure 3 The structure shown does not constitute a limitation on the electronic device and may include fewer or more components than shown, or combine certain components, or have different component arrangements.

[0076] For example, although not shown, the electronic device may also include a power supply (such as a battery) to power the various components. Preferably, the power supply can be logically connected to the at least one processor 10 through a power management device, thereby enabling functions such as charging management, discharging management, and power consumption management. The power supply may also include one or more DC or AC power supplies, recharging devices, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components. The electronic device may also include various sensors, Bluetooth modules, Wi-Fi modules, etc., which will not be described in detail here.

[0077] It should be understood that the embodiments described are for illustrative purposes only and are not limited to this structure in the scope of the patent application.

[0078] The memory 11 in the electronic device stores a pipeline generation method program for multi-chip variants, which is a combination of multiple instructions that, when run in the processor 10, can achieve the following: Obtain the chip family description file, which contains base class definition fields and variant definition fields. The variant definition fields include inheritance declaration fields, architecture fields, and feature list fields. The chip family description file is parsed to obtain a parsed file, and a key-value pair tree structure is constructed based on the parsed file; Based on the inheritance declaration fields in the key-value tree structure, a depth-first recursive parsing is performed, tracing upwards along the inheritance chain to the preset root class, and merging the attributes of the parent node and child node to obtain a full variant configuration list, which does not contain inheritance reference data; Based on the feature list field in the full variant configuration list and the preset feature mapping table, the target macro definition parameters are generated, and the kernel configuration file path is extracted based on the variant definition field to generate the kernel configuration loading command. Extract the architecture fields from the full variant configuration list to match the target cross-toolchain, combine the target macro definition parameters and kernel configuration loading commands to populate the preset pipeline template, and generate the build pipeline definition file.

[0079] Specifically, the specific implementation method of the processor 10 for the above instructions can be referred to the description of the relevant steps in the corresponding embodiment of the accompanying drawings, and will not be repeated here.

[0080] Furthermore, if the modules / units integrated in the electronic device 1 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. The computer-readable storage medium can be volatile or non-volatile. For example, the computer-readable medium may include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, or a read-only memory (ROM).

[0081] The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor of an electronic device, can perform the following: Obtain the chip family description file, which contains base class definition fields and variant definition fields. The variant definition fields include inheritance declaration fields, architecture fields, and feature list fields. The chip family description file is parsed to obtain a parsed file, and a key-value pair tree structure is constructed based on the parsed file; Based on the inheritance declaration fields in the key-value tree structure, a depth-first recursive parsing is performed, tracing upwards along the inheritance chain to the preset root class, and merging the attributes of the parent node and child node to obtain a full variant configuration list, which does not contain inheritance reference data; Based on the feature list field in the full variant configuration list and the preset feature mapping table, the target macro definition parameters are generated, and the kernel configuration file path is extracted based on the variant definition field to generate the kernel configuration loading command. Extract the architecture fields from the full variant configuration list to match the target cross-toolchain, combine the target macro definition parameters and kernel configuration loading commands to populate the preset pipeline template, and generate the build pipeline definition file.

[0082] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0083] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0084] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0085] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0086] Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within the invention. No appended diagram markings in the claims should be construed as limiting the scope of the claims.

[0087] The blockchain referred to in this invention is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0088] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0089] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a system claim may also be implemented by a single unit or device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any specific order.

[0090] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A method for building a pipeline for multiple chip variants, characterized in that, The method includes: Obtain the chip family description file, which contains base class definition fields and variant definition fields. The variant definition fields include inheritance declaration fields, architecture fields, and feature list fields. The chip family description file is parsed to obtain a parsed file, and a key-value pair tree structure is constructed based on the parsed file; Based on the inheritance declaration fields in the key-value tree structure, a depth-first recursive parsing is performed, tracing upwards along the inheritance chain to the preset root class, and merging the attributes of the parent node and child node to obtain a full variant configuration list, which does not contain inheritance reference data; Based on the feature list field in the full variant configuration list and the preset feature mapping table, the target macro definition parameters are generated, and the kernel configuration file path is extracted based on the variant definition field to generate the kernel configuration loading command. Extract the architecture fields from the full variant configuration list to match the target cross-toolchain, combine the target macro definition parameters and kernel configuration loading commands to populate the preset pipeline template, and generate the build pipeline definition file.

2. The method for building a pipeline for multiple chip variants as described in claim 1, characterized in that, The process of merging the attributes of parent and child nodes to obtain a full variant configuration list includes: Identify the data type of the attribute to be merged; When the data type is a scalar type, the attribute value explicitly declared in the child node overrides the attribute value with the same name in the parent node; When the data type is a list, the list data of the parent node is converted into the first set, the list data of the child node is converted into the second set, the first set and the second set are combined, and the result is used as the target attribute value after merging.

3. The method for building a pipeline for multiple chip variants as described in claim 2, characterized in that, The attributes corresponding to the scalar type include architecture type, flash memory capacity limit, memory capacity region division, compiler path, and memory layout linker script path. The attributes corresponding to the list type include a set of firmware feature modules.

4. The method for building a pipeline for multiple chip variants as described in claim 1, characterized in that, The process of generating target macro definition parameters based on the feature list fields in the full variant configuration list and a preset feature mapping table, and extracting the kernel configuration file path based on the variant definition fields to generate the kernel configuration loading command, includes: Iterate through each feature name in the feature list field, retrieve the corresponding configuration symbol and macro definition by querying the pre-maintained feature name and macro definition lookup table, and append the configuration symbol and macro definition to the compilation parameter set of the corresponding variant to obtain the target macro definition parameter; The configuration declaration field in the variant definition field is mapped to the target kernel configuration file path in the file system, and the target kernel configuration file path is inserted into the corresponding kernel configuration file loading instruction before the preset multi-chip variant build step command to obtain the kernel configuration loading command.

5. The method for building a pipeline for multiple chip variants as described in claim 1, characterized in that, Before obtaining the chip family description file, which includes base class definition fields and variant definition fields, the process also includes an artifact archiving management step: The firmware artifact file name is generated based on the variant definition field. The firmware artifact file name is composed of the chip family name, variant name, version submission identifier and build timestamp. Based on the specific function names contained in the feature list fields, attach corresponding feature tag metadata to the firmware artifact; Generate a separate archive subdirectory based on the variant name, and write the output archive instruction containing the archive subdirectory in the build pipeline definition file.

6. The method for building a pipeline for multiple chip variants as described in claim 1, characterized in that, After generating the build pipeline definition file, a minimal build triggering step based on code changes is also included: Parse the dependency description file output by the code compilation and build the dependency mapping relationship between the source code file and the target firmware variant; When changes to the codebase are detected, retrieve the list of changed files; Query the list of change files in the dependency mapping relationship, extract the set of affected associated variants, and trigger only the single variant build step corresponding to the set of associated variants in the build pipeline definition file.

7. The method for building a pipeline for multiple chip variants as described in claim 6, characterized in that, The dependency description file output by the parsed code compilation constructs the dependency mapping relationship between the source code file and the target firmware variant, including: After the full build task is completed, iterate through the dependency description files in the build directory corresponding to each variant; Extract the header file paths and corresponding source code file lists recorded in the dependency description file; The extracted list of source code files is associated with the identification information of the current variant, and the association is stored in the dependency mapping relationship.

8. A build pipeline for multiple chip variants, characterized in that, The apparatus can implement the construction pipeline generation method for multi-chip variants as described in any one of claims 1 to 7, and the apparatus includes: The file parsing module is used to obtain a chip family description file, which contains a base class definition field and a variant definition field. The variant definition field contains an inheritance declaration field, an architecture field, and a feature list field. The chip family description file is parsed to obtain a parsed file, and a key-value pair tree structure is constructed based on the parsed file. The configuration derivation module is used to perform depth-first recursive parsing of inheritance declaration fields in the tree structure based on key values, trace up the inheritance chain to the preset root class, and merge the attributes of parent nodes and child nodes to obtain a full variant configuration list, which does not contain inheritance reference data. The pipeline generation module is used to generate target macro definition parameters based on the feature list fields in the full variant configuration list and the preset feature mapping table, and to extract the kernel configuration file path based on the variant definition fields to generate the kernel configuration loading command; it also extracts the architecture fields in the full variant configuration list to match the target cross-toolchain, and combines the target macro definition parameters and the kernel configuration loading command to fill the preset pipeline template to generate the build pipeline definition file.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor to enable the at least one processor to perform the build pipeline generation method for multi-chip variants as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the construction pipeline generation method for multi-chip variants as described in any one of claims 1 to 7.

Images