Compression storage method for multi-version parameters of semiconductor process formula and related products

Abstract

The embodiment of the invention relates to the field of data management, and discloses a semiconductor process formula multi-version parameter compression storage method and related products, and the method comprises the steps: dividing a semiconductor process formula into fixed parameters and variable parameters, and constructing corresponding formula specifications; storing the process formula in a column storage database to create a process formula parameter table, and managing a parameter version by utilizing a versioned merge tree engine; in response to an instruction for modifying the technological formula, inserting a target record into the corresponding technological formula parameter table; based on the materialized view of the target version parameter, in combination with a preset index condition and a set partition, responding to the query instruction; and separating a target field in the parameter so as to carry out fine-grained permission control and access management. According to the scheme, the storage space can be fully utilized, and the data processing efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of data management, and in particular, to a method for compressing and storing multi-version parameters of semiconductor process recipes and related products. Background Art

[0002] In the field of wafer manufacturing software, the Recipe Management System (RMS) plays a crucial role. The RMS is responsible for managing and maintaining a large number of Recipes, which are sets of basic process parameters for manufacturing wafers. At the same time, the RMS is also responsible for managing Recipe Specs, which define constraints such as the value types and ranges that can be taken by the parameters in the Recipe.

[0003] During the wafer manufacturing process, different processes have different Recipes, and the same process may have multiple versions of Recipes and Recipe Specs. There may be only minor differences between these versions, but these differences can have a significant impact on the quality and performance of the final product. Over time, this data accumulates into a vast amount of information. Traditional row-based storage databases may face problems such as wasted space and degraded performance when storing a large number of Recipes and Recipe Specs.

[0004] Therefore, there is an urgent need for a technical solution that can make full use of storage space and improve data processing efficiency. Summary of the Invention

[0005] An object of this application is to provide a method for compressing and storing multi-version parameters of semiconductor process recipes and related products, at least to solve technical problems such as wasted storage space for existing technology recipe parameters.

[0006] To achieve the above object, some embodiments of this application provide the following aspects: In a first aspect, some embodiments of this application provide a method for compressing and storing multi-version parameters of semiconductor process recipes, including: dividing the semiconductor process recipe into fixed parameters and variable parameters, and constructing corresponding recipe specifications; storing the process recipe in a columnar storage database to create a process recipe parameter table, and using a versioned merge tree engine to manage parameter versions; in response to an instruction to modify the process recipe, inserting a target record in the corresponding process recipe parameter table; based on the materialized view of the target version parameters, combining preset index conditions and set partitions to respond to a query instruction; separating target fields in the parameters to perform fine-grained permission control and access management.

[0007] Further, the semiconductor process recipe is divided into fixed parameters and volatile parameters, and the corresponding recipe specifications are constructed, including: dividing the structure of the process recipe data into two parts, fixed parameters and volatile parameters; setting the fixed parameters to include name, model number, and / or software version; defining the volatile parameters to include execution time, flow rate, power, and / or pressure; constructing the structure of the process recipe specifications, including an identifier and a parameter composite structure; and setting parameter name, type, and value fields in the parameter composite structure.

[0008] Further, the process recipe is stored in a columnar storage database to create a process recipe parameter table, and the versioned merge tree engine is used to manage parameter versions, including: selecting a columnar storage database as the implementation platform; creating a parameter table, including identifier, parameter number, type, value, flag, and / or version fields; using the versioned merge tree engine to create a table and setting the flag and version fields; and specifying the identifier as the sorting key of the table.

[0009] Further, in response to an instruction to modify the process recipe, a target record is inserted into the corresponding process recipe parameter table, including: inserting a negative flag record to mark the old data as invalid; inserting a positive flag record, including the updated parameter value and the new version number; and executing the insert statement while writing the invalid record and the update record.

[0010] Further, based on the materialized view of the target version parameters, combined with preset index conditions and set partitions, the query instruction is responded to, including: creating a materialized view that only contains the parameter data of the latest version; using the replacement merge tree engine to create a materialized view and setting the version field; adding common query conditions to the sorting key to optimize the index structure; implementing a partitioning strategy by time or identifier range; and setting the lifecycle management rules of the data.

[0011] Further, the target fields in the parameters are separated to perform fine-grained permission control and access management, including: creating multiple user roles, including administrator, engineer, and operator; assigning corresponding data operation permissions to each role; creating a public view that only contains non-sensitive parameters; creating a desensitized view to mask sensitive parameters; and granting access permissions to the corresponding views to users at different levels.

[0012] In a second aspect, some embodiments of the present application further provide a semiconductor process recipe compressed storage database that applies the storage method described in any one of the above embodiments, characterized by including: obtaining semiconductor process recipe parameters and dividing the parameters into fixed parameters and volatile parameters; and responding to a modification instruction to insert a changed value and the corresponding version information at a target location.

[0013] In a third aspect, some embodiments of the present application further provide a compressed storage device for multi-version parameters of a semiconductor process recipe, including: a processor, a memory, and a system bus; wherein, the processor and the memory are connected through the system bus; the memory is used to store one or more programs, and the one or more programs include instructions that, when executed by the processor, cause the processor to execute the method described in the above embodiments.

[0014] Compared with the related art, in the solution provided by the embodiments of the present application, by using a columnar storage database to store the unchanged and frequently changed parameters respectively, the storage space can be fully utilized and the data processing efficiency can be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] One or more embodiments are illustrated by way of example in the accompanying drawings, which illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are represented as similar elements, unless otherwise specified, and the figures in the drawings do not constitute a scale limitation.

[0016] Figure 1 It is a schematic flowchart of a compressed storage method for multi-version parameters of a semiconductor process recipe provided by an embodiment of the present application; Figure 2 It is an exemplary structural schematic diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0017] Now, various exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. It should be noted that: unless otherwise specifically stated, the relative arrangements, numerical expressions, and numerical values of the components and steps set forth in these embodiments do not limit the scope of the present disclosure.

[0018] Those skilled in the art can understand that terms such as "first" and "second" in the embodiments of the present disclosure are only used to distinguish different steps, devices or modules, etc., and neither represent any specific technical meaning nor indicate an inevitable logical order between them. It should also be understood that in the embodiments of the present disclosure, "a plurality of" may refer to two or more, and "at least one" may refer to one, two or more. It should also be understood that for any component, data or structure mentioned in the embodiments of the present disclosure, without clear limitation or contrary indication in the context, it can generally be understood as one or more. In addition, the term "and / or" in the present disclosure is merely a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in the present disclosure generally represents an "or" relationship between the associated objects before and after. It should also be understood that the present disclosure emphasizes the differences between various embodiments, and the same or similar parts can be referred to each other. For the sake of brevity, they will not be described one by one.

[0019] At the same time, it should be understood that for the sake of description, the sizes of the various parts shown in the drawings are not drawn according to the actual proportional relationship. The following description of at least one exemplary embodiment is actually only illustrative and in no way restricts the present disclosure and its application or use. Technologies, methods and devices known to those of ordinary skill in the relevant art may not be discussed in detail, but where appropriate, the said technologies, methods and devices should be regarded as part of the specification. It should be noted that: similar reference numerals and letters denote similar items in the following drawings, and thus, once an item is defined in one drawing, it does not need to be further discussed in subsequent drawings.

[0020] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts fall within the scope of protection of the present application.

[0021] First Embodiment Figure 1Schematic diagram of a method for compressed storage of multi-version parameters of a semiconductor process recipe provided by an embodiment of the present application. It should be understood that the semiconductor process recipe parameters refer to a series of parameter settings used to control and optimize various process steps during semiconductor manufacturing. These parameters include, but are not limited to, physical quantities such as temperature, pressure, gas flow rate, voltage, current, time, etc., as well as specific operation instructions for various process equipment. Precise control of these parameters is crucial for ensuring the quality, yield, and consistency of semiconductor products.

[0022] An embodiment of the present application provides a method for compressed storage of multi-version parameters of a semiconductor process recipe, aiming to solve problems such as low storage efficiency, complex version management, and poor query performance existing in traditional storage methods when facing a large amount of process recipe data. This method realizes efficient compressed storage and flexible management of process recipe parameters through innovative data structure design and storage strategies.

[0023] As Figure 1 shown, at step S101, the semiconductor process recipe is divided into fixed parameters and variable parameters, and a corresponding recipe specification is constructed. Fixed parameters usually include basic information of the process recipe, such as name, model, and software version, etc., and these parameters are relatively stable during the life cycle of a process recipe. Variable parameters include those parameters that may need to be frequently adjusted during the manufacturing process, such as execution time, flow rate of gas or liquid, radio frequency power, and chamber pressure, etc.

[0024] Specifically, it includes: dividing the structure of the process recipe data into two parts of fixed parameters and variable parameters; setting the fixed parameters to include name, model, and / or software version; defining the variable parameters to include execution time, flow rate, power, and / or pressure; constructing the structure of the process recipe specification, including an identifier and a parameter composite structure; and setting parameter name, type, and value fields in the parameter composite structure.

[0025] In one embodiment, first, it is necessary to design Recipe and Recipe Spec data structures suitable for columnar storage. Taking Recipe as an example, it can be split into two parts of fixed parameters and variable parameters. Example of Recipe data structure: <L <a "recipe-name"> <a "recipe-mdln"> <a "sw-version"> <L <L <U4 1000> <L <a "false"> <a "description"> <a "2019 06 25 14:32:15"> <a "admin"> <a "2019 08 26 17:41:00"> …… <a "3"># Variable Parameter <a "false"> …… > …… > The fixed parameters include: - Recipe-Name: of string type, such as "ETCH_PROCESS_A" - Recipe-MDLN: of string type, such as "ETCHER_MODEL_X" - SW-VERSION: of string type, such as "v2.3.1" The variable parameters can include: - Execution time of steps: of floating-point type, in seconds, such as 3.15 - Gas flow rate: of floating-point type, in sccm (standard cubic centimeters per minute), such as 45.7 - RF power: of integer type, in watts, such as 1250 - Pressure: of floating-point type, in mTorr, such as 52.3 For the Recipe Spec, the following structure can be designed: - spec_id: of integer type, such as 12345 - variable_params: a composite structure containing multiple parameters - param_name: of string type, such as "etch_time" - param_type: of string type, such as "scope" indicating the range type - param_value: of array type, such as [3.0, 3.2] indicating the execution time range This structural design is conducive to achieving efficient data compression and fast query in columnar storage. For example, the RecipeSpec data structure example: { "spec_id": 12345, "variable_params": { ...... "param_xx_time": {"type": "scope", "value": [3.0, 3.2]} #Spec, execution time range ... }, } At step S102, the process recipe is stored in a columnar storage database to create a process recipe parameter table, and a versioned merge tree engine is used to manage parameter versions. When constructing the process recipe specification, the embodiments of the present application adopt a composite data structure. Specifically, the recipe specification includes a unique identifier and a parameter composite structure. The parameter composite structure further includes fields such as parameter name, type, and value. This design allows for flexible definition and storage of various types of parameters while maintaining the consistency and scalability of the data structure. In this way, the embodiments of the present application provide a unified framework for the storage of semiconductor process recipe parameters, capable of adapting to different types of semiconductor manufacturing equipment and process requirements. Secondly, the embodiments of the present application select a columnar storage database as the implementation platform and create a process recipe parameter table. Compared with traditional row-based storage databases, columnar storage databases have significant advantages in processing large amounts of structured data, especially in data compression and fast querying. In the design of the parameter table, fields such as identifier, parameter number, type, value, flag, and version are included.

[0026] The embodiments of the present application introduce a versioned merge tree engine to manage parameter versions. It allows for efficient management and storage of multiple versions of parameter data without copying the entire dataset. By setting the flag and version fields, the system can track the historical changes of each parameter while maintaining data consistency and integrity. In addition, designating the identifier as the sorting key of the table further optimizes the data organization and retrieval efficiency.

[0027] Specifically, it includes: selecting a columnar storage database as the implementation platform; creating a parameter table including identifier, parameter number, type, value, flag, and / or version fields; creating a table using a versioned merge tree engine and setting the flag and version fields; designating the identifier as the sorting key of the table.

[0028] In one embodiment, ClickHouse is selected as the implementation platform because of its excellent performance in large-scale data processing and columnar storage.

[0029] The SQL statement for creating the Recipe parameter table is as follows: CREATE TABLE RecipeParams ( RcpID UInt64, ParamID UInt16, ParamType UInt8, ParamValue String, Sign Int8, Version UInt16 ) ENGINE = VersionedCollapsingMergeTree(Sign, Version) ORDER BY RcpID Table structure description: - RcpID: The unique identifier of the Recipe - ParamID: The unique identifier of the parameter - ParamType: The parameter type (e.g., 1 represents execution time, 2 represents gas flow rate, etc.) - ParamValue: The parameter value, stored as a string to accommodate different types of parameters - Sign: Used to mark the insertion (1) or deletion (-1) of data - Version: Used to track the version changes of the parameters Using the Versioned Collapsing Merge Tree engine can effectively manage the version changes of parameters, automatically merge data with the same version, thereby saving storage space.

[0030] At step S103, in response to the instruction to modify the process recipe, insert a target record into the corresponding process recipe parameter table. Among them, it includes: insert a negative sign record to mark the old data as invalid; insert a positive sign record containing the updated parameter value and the new version number; execute the insert statement and write the invalid record and the update record at the same time.

[0031] Each time the process recipe is modified, a new record will be inserted into the process recipe parameter table, which includes the changed parameter value and the corresponding version information. Through the version number (Version) field, it is possible to quickly find the parameter value of a certain historical version of the process recipe without storing all historical versions of the process recipe in full.

[0032] At the same time, by reasonably using the merge tree engine (Merge Tree Engine) and versioned merge tree engine (Versioned Merge Tree Engine) provided by Click House, it is possible to achieve version management and storage compression of data, thereby saving storage space and improving query performance. The versioned merge tree engine is particularly suitable for storing data with historical versions. It will merge data rows with the same version according to the version number, thereby reducing the occupation of storage space.

[0033] For example, when it is necessary to update the process recipe parameters, the following steps can be adopted: 1. Insert a record with Sign = -1 to indicate the invalidation of the old data.

[0034] 2. Insert a record with Sign = 1, containing the updated parameter values and the new version number.

[0035] For example, update the parameter value with ParamID = 5 in the Recipe with RcpID = 1000: INSERT INTO RecipeParams (RcpID, ParamID, ParamType, ParamValue, Sign, Version) VALUES (1000, 5, 1, '3.15', -1, 1), (1000, 5, 1, '3.20', 1, 2); This mechanism ensures data version control and allows for quickly obtaining the currently valid parameter values by querying the latest version.

[0036] It should be noted that a major advantage of columnar storage is the ability to achieve efficient data compression. Taking the storage of process recipe parameters as an example, using the multi - version data compression method, for different versions of each Recipe and Recipe Spec, only the differences from the previous version are stored, rather than the complete data for each version. This method has a direct impact on improving the performance of the entire system and reducing storage costs.

[0037] Suppose there are N versions of Recipe or Recipe Spec. If the traditional storage method is adopted, that is, each version is stored completely, the total storage size is: S_traditional = N × x, where x is the average storage size of a Recipe or Recipe Spec.

[0038] In the case of adopting version control and differential storage mechanism, the first version is stored completely, while each subsequent version only stores the differences from the previous version. If it is assumed that the storage size of the parameters changed in each version on average is y (y < x), then the total storage size is: S_differential = x + (N - 1) × y. Therefore, the storage space saved by adopting the differential storage mechanism can be expressed as: S_saved = S_traditional - S_differential = N × x - (x + (N - 1) × y). Simplifying this formula, we get: S_saved = (N - 1) × (x - y). This formula shows the amount of storage space that can be saved by adopting version control and differential storage mechanism compared to the traditional complete storage method. In this model, the amount of saved space is proportional to the number of versions N and the average difference size x - y between two versions. When y is much smaller than x, that is, the difference between each version is small, the storage space saved by this storage strategy will be very significant. Suppose a typical process recipe contains 100 parameters, and each parameter occupies 20 bytes on average (considering the storage requirements of different types of parameters). In traditional row storage, each version needs to store all parameters completely. Therefore, storing 10 versions requires: S_traditional = 10 * 100 * 20 = 20,000 bytes.

[0039] In this solution, suppose only 5 parameters are modified on average each time there is an update. Then, storing 10 versions requires: S_differential = (100 * 20) + (9 * 5 * 20) = 2,900 bytes Calculation of compression ratio: Compression ratio = (S_traditional - S_differential) / S_traditional * 100% = (20,000 - 2,900) / 20,000 * 100% ≈ 85.5% This means that by using columnar storage and version control mechanism, about 85.5% of the storage space can be saved. In actual situations, due to the built-in compression algorithm of ClickHouse, the compression effect may be more significant. According to different values of N, x, and y, the following table is obtained, showing the amount of storage space that can be saved by adopting version control and differential storage mechanism compared to the traditional complete storage method:

[0040] For most Recipes or Recipe Specs in practice, the value of y / x is relatively small. That is to say, in most cases, a great deal of space can be saved.

[0041] At step S104, in response to the query instruction, a materialized view based on the target version parameters is combined with the preset index conditions and the set partitions. A materialized view is a pre-computed and stored query result that only contains the parameter data of the latest version, thereby improving the speed of data retrieval. In the embodiments of the present application, a ReplacingMergeTree engine is used to create the materialized view, and a version field is set in the view, which enables the system to efficiently maintain and update the view content.

[0042] In terms of index optimization, in the embodiments of the present application, common query conditions are added to the sorting key, which significantly improves the query efficiency, especially for frequently executed query operations. At the same time, in the embodiments of the present application, a partitioning strategy by time or identifier range is implemented, which not only improves the physical organization of the data but also increases the parallelism of query and maintenance operations. In addition, by setting the data life cycle management rules, the embodiments of the present application achieve the automated management of historical data, effectively controlling the growth of the storage space while retaining the necessary historical information.

[0043] Specifically, it includes: creating a materialized view that only contains the parameter data of the latest version; using a ReplacingMergeTree engine to create the materialized view and setting a version field; adding common query conditions to the sorting key to optimize the index structure; implementing a partitioning strategy by time or identifier range; setting the data life cycle management rules.

[0044] Furthermore, in order to improve the query efficiency, the following strategies can be adopted: Using a materialized view: Creating a materialized view that only contains the parameter data of the latest version can accelerate common queries.

[0045] CREATE MATERIALIZED VIEW RecipeParamsLatest ENGINE = ReplacingMergeTree(Version) ORDER BY (RcpID, ParamID) AS SELECT RcpID, ParamID, ParamType, ParamValue, Version FROM RecipeParams WHERE Sign = 1; Index Optimization: According to the actual query pattern, common query conditions such as (RcpID, ParamType) can be added to the ORDER BY clause to improve the query speed of specific types of parameters.

[0046] Partitioning Strategy: If the data volume is huge, partitioning by time or RcpID range can be considered to improve query and management efficiency.

[0047] For example, partitioning by month: ALTER TABLE RecipeParams MODIFY TTL toDateTime(CreatedAt) + INTERVAL 1 MONTH, SETTINGS index_granularity = 8192; This can automatically manage the data lifecycle, and expired data will be automatically deleted or moved to cold storage.

[0048] At step S105, the target fields in the parameters are separated for fine-grained permission control and access management. By separating the target fields in the parameters, fine-grained permission control and access management of sensitive data are achieved. Further, embodiments of the present application create multiple user roles, such as administrators, engineers, and operators, and assign corresponding data operation permissions to each role. This hierarchical permission management mechanism ensures data security while meeting the access needs of different user groups.

[0049] To further enhance data security, embodiments of the present application create a public view that only contains non-sensitive parameters, and a desensitized view that masks sensitive parameters. This design allows the system to share data among users with different security levels while protecting sensitive information from unauthorized access. By granting access permissions to the corresponding views for different levels of users, embodiments of the present application implement a flexible and secure data sharing mechanism.

[0050] Specifically, it includes: creating multiple user roles, including administrators, engineers, and operators; assigning corresponding data operation permissions to each role; creating a public view that only contains non-sensitive parameters; creating a desensitized view to mask sensitive parameters; and granting access permissions to the corresponding views for different levels of users.

[0051] In one embodiment, to achieve fine-grained permission control, the following method can be adopted: Role-Based Access Control (RBAC): Create different user roles, such as administrators, engineers, operators, etc., and assign appropriate permissions to each role.

[0052] CREATE ROLE recipe_admin; CREATE ROLE recipe_engineer; CREATE ROLE recipe_operator; GRANT SELECT, INSERT, UPDATE ON RecipeParams TO recipe_admin; GRANT SELECT ON RecipeParams TO recipe_engineer; GRANT SELECT(RcpID, ParamID, ParamValue) ON RecipeParams TO recipe_operator; Column-level permission control: Implement more stringent access control for sensitive parameters. For example, a view can be created that only contains non-sensitive parameters: CREATE VIEW RecipeParamsPublic AS SELECT RcpID, ParamID, ParamValue FROM RecipeParams WHERE ParamType NOT IN (3, 4, 5); -- Assume 3, 4, 5 are sensitive parameter types GRANT SELECT ON RecipeParamsPublic TO recipe_operator; Data masking: For sensitive data that needs to be displayed but cannot be fully public, a masked view can be created: CREATE VIEW RecipeParamsMasked AS SELECT RcpID, ParamID, CASE WHEN ParamType IN (3, 4, 5) THEN '****' ELSE ParamValue END AS ParamValue FROM RecipeParams; This can ensure that only authorized users can access sensitive parameter data, while providing the required access permissions for users at different levels.

[0053] In summary, the solution of the embodiment of the present application uses a columnar storage database. In view of the characteristics of multi-version information of Recipe and Recipe Spec, a targeted data compression strategy is implemented, storing the unchanged and frequently changed parameters separately, thereby greatly compressing the storage space. In contrast, the row-by-row storage of traditional row-based storage databases will lead to space waste and increased storage costs. The solution realizes the ability to quickly respond to complex query requests at a large data volume through optimizing the model system and library table design. On the contrary, the performance of traditional row-based storage databases deteriorates when a single table is too large, resulting in low query efficiency and extended response time. The solution separates a large number of unchanged parameter fields and a small number of volatile parameter fields, and can implement a more fine-grained permission control and access management mechanism by column respectively, ensuring that only authorized users can access the column-level parameter data of high confidentiality level.

[0054] Second Embodiment Furthermore, the embodiment of the present application also provides a semiconductor process recipe compression storage database applying the storage method described in any one of the above embodiments, including: acquiring semiconductor process recipe parameters and dividing the parameters into fixed parameters and volatile parameters; responding to a modification instruction to insert a changed value and corresponding version information at a target position.

[0055] Third Embodiment Furthermore, the embodiment of the present application also provides a compression storage device for multi-version parameters of a semiconductor process recipe, including: collecting semiconductor process recipe parameters on one or more production devices, and configuring a data security area to store the stored process recipe parameters and / or perform permission control including data access, data transmission, and / or data editing; remotely deleting the process recipe parameters on the collected production devices; in response to a request from a production device to process a semiconductor, synchronously downloading the stored process recipe parameters to all corresponding production devices, and remotely deleting the process recipe parameters on the production devices after processing is completed.

[0056] Furthermore, the embodiment of the present application also provides a semiconductor processing device, including: uploading the configured process recipe parameters to a cloud storage device and performing local deletion; sending a data request to the cloud storage device before processing a semiconductor to download the corresponding process recipe parameters, and locally deleting the process recipe parameters after processing is completed.

[0057] In addition, some embodiments of the present application also provide an electronic device. The electronic device can be various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and so on. The electronic device can also be various forms of mobile devices, such as personal digital processors, cellular phones, smart phones, wearable devices, and other similar computing devices.

[0058] The electronic device includes: one or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform the steps of the method provided in any one or more of the above embodiments. Figure 2 Disclosed is an exemplary structural diagram of the electronic device. As Figure 2As shown, the electronic device includes: one or more processors 1101, a memory 1102, and interfaces for connecting various components, including a high-speed interface and a low-speed interface. Each component is interconnected using different buses and can be mounted on a common motherboard or otherwise as required. The processor can process instructions executed within the electronic device, including instructions stored in the memory or on the memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, with each device providing some necessary operations (such as an array of servers, a set of blade servers, or a multi-processor system). Among them, the components, their connections and relationships, and their functions shown in the embodiments of the present application are only examples and are not intended to limit the implementation of the present application described and / or claimed in the embodiments of the present application.

[0059] The electronic device may further include: an input device 1103 and an output device 1104. The processor 1101, the memory 1102, the input device 1103, and the output device 1104 can be connected by a bus or other means. Figure 2 Taking connection by bus as an example.

[0060] The input device 1103 can receive input digital or character information and generate key signal inputs related to user settings and function controls of the electronic device, such as input devices like a touch screen, a keypad, a mouse, a trackpad, a touchpad, a pointing stick, one or more mouse buttons, a trackball, a joystick, etc. The output device 1104 can include a display device, an auxiliary lighting device (such as an LED), and a haptic feedback device (such as a vibration motor), etc. The display device can include, but is not limited to, a liquid crystal display (LCD), a light-emitting diode (LED) display, and a plasma display. In some embodiments, the display device can be a touch screen.

[0061] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device for displaying information to the user (such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and a pointing device (such as a mouse or a trackball), through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (such as visual feedback, auditory feedback, or haptic feedback); and input from the user can be received in any form (including voice input, speech input, or haptic input).

[0062] In the embodiments of the present application, a computer program / instruction is stored on a computer-readable medium. When the computer program / instruction is executed by a processor, the steps of the method provided in any one or more of the above embodiments are implemented. The computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist separately without being assembled into the device. The above computer-readable medium carries one or more computer-readable instructions.

[0063] The memory 1102 can be used as a non-transitory computer-readable storage medium for storing non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, so as to implement the program instructions / modules corresponding to the method provided in any one or more of the above embodiments of the present application.

[0064] The memory 1102 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 1102 may include a high-speed random access memory, and may also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some embodiments, the memory 1102 may optionally include a memory remotely provided relative to the processor 1101, and these remote memories may be connected to the electronic device through a network. Examples of the above network include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0065] It should be noted that the computer-readable medium described in the present application may be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. The computer-readable medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer-readable medium may be any tangible medium that contains or stores a program, and this program can be used by or in combination with an instruction execution system, apparatus, or device.

[0066] A computer-readable medium includes both permanent and non-permanent, removable and non-removable media, and can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device.

[0067] Computer program code for performing the operations of the present application can be written in one or more programming languages or combinations thereof. The programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., by using an Internet service provider to connect through the Internet).

[0068] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. For example, an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device can be used. In some embodiments, the software program of the present application can be executed by a processor to implement the above steps or functions. Similarly, the software program of the present application (including related data structures) can be stored in a computer-readable recording medium, such as a RAM memory, a magnetic or optical drive, or a floppy disk and similar devices. Additionally, some steps or functions of the present application can be implemented by hardware, for example, as a circuit that cooperates with a processor to execute each step or function.

[0069] The computer program product provided by the embodiments of the present application includes one or more computer programs / instructions. When the computer programs / instructions are executed by a processor, they wholly or partly generate the processes or functions described in the embodiments of the present application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from a website, a computer, a server, or a data center to another website, a computer, a server, or a data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, a data center, etc. that incorporates one or more available media. The available medium may be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (SSD)).

[0070] The flowcharts or block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of devices, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code that contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combinations of blocks in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system for performing the specified functions or operations, or by a combination of dedicated hardware and computer instructions.

[0071] The scope of the present application is defined by the appended claims rather than the above description. Therefore, all changes that fall within the meaning and scope of the equivalent elements of the claims are intended to be included in the present application. Any reference signs in the claims should not be construed as limiting the claims concerned. In addition, it is obvious that the word "comprising" does not exclude other elements or steps, and the singular does not exclude the plural. The multiple elements or devices stated in the apparatus claims may also be implemented by one element or device through software or hardware. The words "first", "second", etc. are only used for distinguishing descriptions and do not represent any specific order, nor can they be understood as indicating or implying relative importance.

[0072] As described above, it is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present application can easily make changes or substitutions, which should all be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims, and the above embodiments should be regarded as exemplary and non-restrictive.

Claims

1. A method for compressing and storing multi-version parameters of a semiconductor process recipe, characterized in that: include: Divide semiconductor process recipes into fixed parameters and variable parameters, and build corresponding recipe specifications; Store process recipes in a column storage database to create a process recipe parameter table and use a versioned merge tree engine to manage parameter versions; In response to an instruction to modify a process recipe, a target record is inserted into a corresponding process recipe parameter table; The materialized view based on the target version parameters responds to the query instructions in combination with the preset index conditions and set partitions; Separate the target fields in the parameters for fine-grained permission control and access management.

2. The compression storage method according to claim 1, characterized in that: in, Divide semiconductor process recipes into fixed parameters and variable parameters, and build corresponding recipe specifications, including: The structure of process recipe data is divided into two parts: fixed parameters and variable parameters; Setting fixed parameters includes name, model and / or software version; Defining variable parameters including execution time, flow, power and / or pressure; Build a structure for process recipe specifications, including identifier and parameter composite structures; Set the parameter name, type, and value fields in the parameter compound structure.

3. The compression storage method according to claim 1, characterized in that: in, Store process recipes in a columnar storage database to create a process recipe parameter table and use a versioned merge tree engine to manage parameter versions, including: Choose a column storage database as the implementation platform; Create a parameter table containing identifier, parameter number, type, value, flags and / or version fields; Create a table using the versioned merge-tree engine and set flags and version fields; Specifies the identifier as the sort key for the table.

4. The compression storage method according to claim 1, characterized in that: in, In response to the instruction to modify the process recipe, insert a target record into the corresponding process recipe parameter table, including: Insert a negative value flag record to mark the old data as invalid; Insert a positive value mark record containing the updated parameter value and new version number; Execute the insert statement and write both invalid and updated records.

5. The compression storage method according to claim 1, characterized in that: in, The materialized view based on the target version parameters, combined with the preset index conditions and set partitions, responds to the query instructions, including: Create a materialized view that contains only the latest version of parameter data; Create a materialized view using the replace merge tree engine and set the version field; Add common query conditions to the sort key to optimize the index structure; Implement partitioning strategies by time or identifier range; Set data lifecycle management rules.

6. The compression storage method according to claim 1, characterized in that: in, Separate the target fields in the parameters to perform fine-grained permission control and access management, including: Create multiple user roles, including administrators, engineers, and operators; Assign corresponding data operation permissions to each role; Create public views that contain only non-sensitive parameters; Create a desensitized view and mask sensitive parameters; Grant access permissions to corresponding views to users of different levels.

7. A semiconductor process recipe compression storage database using the storage method according to any one of claims 1 to 6, characterized in that: include: Acquire semiconductor process recipe parameters, and divide the parameters into fixed parameters and variable parameters; Respond to the modification instruction to insert the changed value and corresponding version information at the target location.

8. A compression storage device for multi-version parameters of semiconductor process recipes, characterized in that: include: A processor, a memory, and a system bus; wherein the processor and the memory are connected via the system bus; The memory is used to store one or more programs, wherein the one or more programs include instructions, and when the instructions are executed by the processor, the processor executes the method according to any one of claims 1 to 6.

Images