Method for constructing basic platform of chip design EDA environment

Abstract

The application discloses a chip design EDA environment basic platform construction method, belongs to the field of computer data processing and digital computing technology, which comprises the following steps: acquiring design task description information and tool calling record and performing analysis, generating environment demand portrait and performing information extraction and normalization processing, generating environment fingerprint, scanning and analyzing construction nodes and performing closure processing, obtaining dependency closure and performing detection and arrangement, generating construction plan in combination with resource constraint information, executing assembly mapping, generating environment package and environment proof information, issuing to execution nodes and generating injection configuration, starting design task and collecting running evidence, and generating running consistency report. The application adopts environment demand portrait extraction and environment fingerprint coding technology to generate tamper-proof environment package, and combines dependency closure conflict resolution and running evidence consistency comparison mechanism, so that the automatic construction and deterministic execution of cross-computing-node running environment can be realized.

Description

Technical Field

[0001] This invention relates to the field of computer data processing and digital computing technology, and in particular to a method for constructing a basic platform for a chip design EDA environment. Background Technology

[0002] Electronic Design Automation (EDA) technology is a core support platform in the chip development process, encompassing complex computational tasks such as logic synthesis, physical placement, and timing simulation. The execution of these tasks heavily relies on the coordinated operation of the underlying operating system kernel, specific compiler versions, and a vast array of dynamic link libraries. The basic platform construction method for chip design EDA environments aims to provide standardized and isolated digital computing and data processing runtime spaces for these complex computational tasks, ensuring that toolchains at different design stages can accurately access underlying hardware resources.

[0003] Existing compute node environment construction solutions typically deploy toolchains by writing static configuration scripts or directly cloning virtual machine images. Engineers pre-compile a dependency list for various design tools on a central server, install system components one by one using package management tools, and hardcode environment variable modification commands into the startup scripts. In a multi-node cluster environment, the operations and maintenance system distributes these pre-configured image files or scripts to each compute node, where the node's own daemon performs environment initialization operations. The deployment methods described above, using static scripts and image cloning, struggle to dynamically resolve fine-grained dependency boundaries of different design tasks on underlying dynamic libraries when dealing with scenarios involving the parallel operation of multiple toolchain versions. This can easily lead to version conflicts of shared components. Furthermore, the lack of unique identifiers for environment configuration items and runtime consistency verification mechanisms means that when the underlying operating system of a compute node is patched or the hardware architecture changes, the pre-defined configuration scripts cannot adaptively adjust path mapping rules. This results in frequent library file loading failures or execution path resolution errors during cross-node scheduling of design tasks. Summary of the Invention

[0004] To address the aforementioned issues, this invention provides a basic platform construction method for chip design EDA environments. It employs environment requirement profiling and environment fingerprinting technology to generate tamper-proof environment packages, and combines dependency closure conflict resolution and runtime evidence consistency comparison mechanisms to achieve automated construction and deterministic execution of cross-computing node runtime environments.

[0005] The above objectives can be achieved through the following approach: A method for constructing a basic platform for a chip design EDA environment includes: acquiring and parsing design task description information and tool call records to generate an environment requirement profile; extracting tool identification information, dependency type information, and runtime constraint information from the environment requirement profile and normalizing them to generate an environment fingerprint; performing dependency scanning and path parsing on the construction nodes based on the environment fingerprint, and performing closure processing to obtain dependency closures; performing conflict detection and sequence arrangement on the dependency closures and generating a construction plan based on resource constraint information, wherein the construction plan includes a sequence of construction steps and verification point information; executing dependency acquisition, component assembly, and entry mapping according to the construction plan to generate an environment package and generate environment proof information associated with the environment fingerprint; distributing the environment package and the environment proof information to the execution nodes and generating an injection configuration, wherein the injection configuration is used to establish a runtime context consistent with the environment package at the execution nodes; starting the design task based on the injection configuration and collecting runtime evidence to generate a runtime consistency report.

[0006] Optionally, the process of generating the environment requirement profile includes: obtaining task stage information and input / output path information from the design task description information to generate task stage elements; obtaining tool entry information and parameter expansion information from the tool call record to generate call behavior elements; and integrating the task stage elements and the call behavior elements and annotating the dependency types to generate the environment requirement profile.

[0007] Optionally, generating the environment fingerprint includes: extracting tool version clues and component boundary clues from the environment requirement profile to generate a version clue set; performing a consistent representation on the version clue set and generating a summary to obtain a fingerprint summary; and combining and encoding the fingerprint summary with the runtime constraint information to generate an environment fingerprint.

[0008] Optionally, obtaining the dependency closure includes: generating an entry point location result based on the installation location of the environment fingerprinting tool and the script entry point location; performing dynamic link resolution and interpreter resolution on the entry point location result to generate a dependency graph; and performing reachability expansion and missing item completion on the dependency graph to generate a dependency closure.

[0009] Optionally, the step of performing conflict detection and sequencing on the dependency closures and generating a build plan in conjunction with resource constraint information includes: performing version conflict identification and alternative candidate generation on the dependency closures to obtain a conflict set and a candidate set; performing conflict resolution based on the conflict set and the candidate set and generating component selection results to obtain resolved dependency closures; performing topological sorting on the resolved dependency closures and extracting key verification nodes according to the environment requirement profile to generate verification point information; performing topological sorting on the resolved dependency closures and inserting the verification point information to generate a build plan.

[0010] Optionally, generating an environment package and generating environment proof information associated with the environment fingerprint includes: performing layered assembly on the dependent closures according to the build plan and generating a hierarchical structure to obtain an environment package structure; generating tool entry mapping and library loading rules based on the environment package structure to obtain environment package metadata; performing digest signing and association recording on the environment package metadata and the environment fingerprint to generate environment proof information and encapsulate it to obtain an environment package.

[0011] Optionally, the generation of injection configuration includes: obtaining node capability information and existing environment information of the execution node, and generating a node environment baseline; performing difference calculation between the node environment baseline and the environment package metadata, and generating an injection difference set; generating path injection rules, variable injection rules and entry redirection rules based on the injection difference set, obtaining the injection configuration and completing its distribution.

[0012] Optionally, generating the runtime consistency report includes: collecting the actual parsing path of the tool, the actual loading summary of the library, and the variable expansion results of the execution node based on the injection configuration to generate runtime evidence; comparing the runtime evidence with the environment proof information to generate a consistency judgment result; and generating difference items and impact ranges based on the consistency judgment result to obtain the runtime consistency report.

[0013] Optionally, the method further includes: extracting discrepancy entries from the operational consistency report and performing attribution classification to generate discrepancy attribution results; selecting an environment package version based on the discrepancy attribution results and generating a rollback instruction to obtain a rollback execution plan; executing the rollback execution plan and regenerating operational evidence to obtain rollback verification results and updating the environment requirement profile.

[0014] Based on the same inventive concept, this invention also provides a basic platform construction system for a chip design EDA environment. The system includes: a profile generation module for acquiring and parsing design task description information and tool call records to generate an environment requirement profile; a fingerprint generation module for extracting tool identification information, dependency type information, and runtime constraint information from the environment requirement profile and performing normalization processing to generate an environment fingerprint; a closure construction module for performing dependency scanning and path parsing on construction nodes based on the environment fingerprint, and performing closure processing to obtain dependency closures; a plan generation module for performing conflict detection and sequence arrangement on the dependency closures and generating a construction plan in conjunction with resource constraint information, the construction plan including a sequence of construction steps and verification point information; an environment packaging module for executing dependency acquisition, component assembly, and entry mapping according to the construction plan, generating an environment package and generating environment proof information associated with the environment fingerprint; an injection delivery module for delivering the environment package and the environment proof information to execution nodes and generating an injection configuration, the injection configuration being used to establish a runtime context consistent with the environment package at the execution node; and a verification report module for starting the design task based on the injection configuration and collecting runtime evidence to generate a runtime consistency report.

[0015] Compared with the prior art, the present invention has the following advantages: 1. This invention generates an environment requirement profile by parsing design task description information and tool call records, and extracts tool version clues and component boundary clues for consistent expression and combination encoding to generate an environment fingerprint. This achieves accurate quantification and unique identification of the dependency characteristics of the computing node's running environment, reduces the parameter omission problem caused by human experience in the traditional environment configuration process, and provides standardized digital credentials for subsequent automated construction.

[0016] 2. This invention performs dependency scanning and closure processing on the construction nodes based on environment fingerprints. After identifying and resolving version conflicts, it generates a construction plan containing verification point information by combining resource constraint information. Then, it completes layered assembly and digest signature encapsulation to obtain the environment package, ensuring the integrity and version compatibility of the dependency relationship between the underlying system library and the top-level application tool, and constructing a self-contained runtime context entity with anti-tampering characteristics.

[0017] 3. This invention distributes the environment package to the execution node and generates the injection configuration. After the design task is started, it collects the running evidence and environment proof information for consistency comparison. Based on the difference attribution results, it executes the rollback plan and updates the environment requirement profile, establishing a closed-loop control mechanism from environment distribution, operation monitoring to anomaly recovery, ensuring the environment determinism and system fault tolerance when executing chip design tasks across physical nodes.

[0018] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

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

[0020] Figure 1 This is a flowchart illustrating the basic platform construction method of the chip design EDA environment according to an embodiment of the present invention.

[0021] Figure 2 This is a graph illustrating the dependency closure construction process in an embodiment of the present invention.

[0022] Figure 3 This is a schematic diagram of the convergence trajectory of environment verification and profile update in an embodiment of the present invention.

[0023] Figure 4 This is a schematic diagram of the basic platform construction system for the chip design EDA environment according to an embodiment of the present invention. Detailed Implementation

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

[0025] Reference Figure 1 One embodiment of the present invention proposes a basic platform construction method for chip design EDA environment. It uses environment requirement profile extraction and environment fingerprint encoding technology to generate tamper-proof environment packages, and combines dependency closure conflict resolution and runtime evidence consistency comparison mechanism to realize automated construction and deterministic execution of cross-computing node runtime environment.

[0026] The method described in this embodiment specifically includes: Obtain and parse design task description information and tool call records to generate an environment requirement profile; Optionally, the generated environment requirement profile includes: Obtain task phase information and input / output path information from the design task description information, and generate task phase elements; Obtain tool entry information and parameter expansion information from tool call records to generate call behavior elements; By integrating the task stage elements and the invocation behavior elements and annotating the dependency types, an environment requirement profile is generated.

[0027] Specifically, the process first obtains the design task description information. In engineering practice, this information is typically a flow control script written in scripting languages ​​such as Tcl or Perl, or a structured flow definition file based on formats such as XML or YAML. The module's built-in parsing engine performs syntax analysis and pattern matching on the input script according to a preset set of parsing rules. For example, by recognizing keywords such as "set_current_step" or "run_synthesis_stage", it segments the task stage information, such as logic synthesis, place and route, and static timing analysis. Simultaneously, by matching instructions such as "read_verilog", "write_netlist", and "load_sdc", it extracts their associated file paths as input and output path information. The key parameter in this process is the stage identification keyword list, which contains at least 10-20 verbs or instructions related to the EDA process. Finally, the parsing results are structured to form task stage elements, whose data structure is a series of tuples, each containing a stage identifier, a set of input files, and a set of output files.

[0028] Tool call logs are parsed to generate call behavior elements. Tool call logs are read, typically from the shell history logs of task execution nodes, job logs from the Load Sharing Facility (LFS) scheduling system, or runtime snapshots collected by system call tracing tools such as "strace". A regular expression-based log parser extracts the complete tool call command line from the log text. This command line is broken down into tool entry information (the absolute path to the tool executable) and parameter expansion information (all command-line switches, parameter values, and environment variables passed to the tool). Extracting parameter expansion information is particularly critical because it directly exposes implicit dependencies such as specific library versions, configuration file paths, or license servers. A key parameter in this process is the call chain depth threshold, set to 2-5 levels, used to trace sub-tools or scripts called by the main tool. The extracted information is formatted into call behavior elements, with a data structure of a mapping table using the tool entry as the key and the parameter list and environment variable dictionary as values.

[0029] A fusion algorithm is executed to associate task phase elements with invocation behavior elements. The association is based on the temporal proximity of the task phase and the tool invocation, or by matching a specific file with a tool invocation that uses that file using input / output path information. After fusion, a dependency type annotation process is initiated. This process applies a predefined dependency type annotation rule set containing a series of pattern matching rules. For example, paths ending in ".so" or ".a" are annotated as "DEP_TYPE_SHARED_LIB"; paths containing keywords such as PDKProcessDevelopmentKit are annotated as "DEP_TYPE_PDK_LIB"; and paths pointing to executable files are annotated as "DEP_TYPE_TOOL_BIN". This process can be represented by a formal model, which yields an environmental requirement profile. ,have: ; in, and These are the specific stage elements and call elements within the task stage element set and the call behavior element set, respectively. For the timestamp of stage s; The timestamp of calling c; The time proximity threshold is a preset time difference limit, such as 2 seconds. This is the set of files for stage s, containing the input and output file paths for that stage; This is the set of paths for calling C, including all file paths, library paths, executable file paths, etc., extracted from the tool's command line. That is, if the file used in a stage intersects with the path that appears in the call, it is considered that there is a data flow relationship between the two. This refers to the path to the dependency, such as / usr / lib / libc.so; That is, classify path p according to the predefined dependency type annotation rule set mentioned above; Each path p that meets the conditions generates a key-value pair or tuple, forming a node in the environment requirement profile. This formula means that iterates through all combinations of stage elements and call elements; when the conditions of temporal proximity or file path intersection are met, all dependent paths generated in that call and their type labels are included in the environment requirement profile set; combinations that do not meet the conditions do not contribute anything, rather than leaving the entire profile empty. The final generated environment requirement profile is a semantically rich dependency graph that not only lists all dependencies but also clearly describes the role and type of each dependency in the design process, providing unambiguous input for subsequent automated environment construction.

[0030] For example, taking a static timing analysis design task for a digital signal processor core named "DSP_CORE_v2" as an example, the flow control script for this task is run_sta.tcl. First, the run_sta.tcl file is obtained as the design task description information. The script content is read, and the "STA_setup", "STA_run", and "STA_report" task stage information are identified by using the "set_current_step" instruction in the stage identification keyword list. Next, the "read_sdc" and "read_verilog" instructions are matched to extract the input path information, such as / proj / dsp_v2 / designs / dsp_core_v2.v, etc.; at the same time, the "write_report" instruction is matched to extract the output path information, such as / proj / dsp_v2 / outputs / sta_summary.rpt. This information is combined into task stage elements. At the same time, the tool call record, namely the job log named job_12345.log, is obtained. The log parser extracts the complete tool call command lines from the log using regular expressions. The command line is broken down, yielding the tool entry information ` / opt / synopsys / primetime / Q-2019.12 / bin / pt_shell` and parameter expansion information `-f run_sta.tcl`... This information constitutes the call behavior elements. Finally, the fusion algorithm is executed. Because the input file ` / proj / dsp_v2 / constraints / timing.sdc` in the task phase elements is indirectly related to the parameter `-f run_sta.tcl` in the call behavior elements, `run_sta.tcl` will read `timing.sdc` and satisfy... The conditions are used to associate the two and label them with dependency types. For example, the path / opt / synopsys / primetime / Q-2019.12 / lib / libtcl.so is found from the tool call. According to the predefined rules, it is labeled as DEP_TYPE_SHARED_LIB because its suffix is ​​.so; another path / pdk / foundry_x / 1p8m / V1.2 / libs / ff_lib.db is labeled as DEP_TYPE_PDK_LIB because it contains the keyword PDK. This process can be expressed by a formula to obtain the environment requirement profile. Assuming that the timestamp of the stage STA_run is 1678886405.5, the timestamp of calling pt_shell is 1678886405.2, and the time proximity threshold is 2 seconds, since This satisfies the time proximity requirement, therefore the path / pdk / foundry_x / 1p8m / V1.2 / libs / ff_lib.db and That is, DEP_TYPE_PDK_ The LIB pairs are added to the environment requirements profile. Ultimately, all dependencies that meet the criteria and their types are collected, forming a structured environment requirements profile that includes all tools, libraries, PDK files, and their functional categories. Through deep analysis and fusion of design task descriptions and tool call records, a comprehensive and semantically rich environment requirements profile can be automatically generated, providing accurate and unambiguous input for subsequent precise environment fingerprint generation and automated environment construction.

[0031] Extract tool identification information, dependency type information, and runtime constraint information from the environmental requirement profile and perform normalization processing to generate an environmental fingerprint; Optionally, the generated environment fingerprint includes: Extract tool version clues and component boundary clues from the environmental requirement profile to generate a version clue set; The set of version clues is represented in a consistent manner and a summary is generated to obtain a fingerprint summary; The fingerprint digest is combined with the operational constraint information and encoded to generate an environmental fingerprint.

[0032] Specifically, this method comprises the following three core engineering steps. The first step is to extract clues to generate a version clue set. The system receives an environment requirements profile as input and scans it using a version extraction rule base. This rule base contains 15-30 regular expressions targeting the version number format and installation path structure of mainstream EDA vendor tools. Using these rules, tool version clues are extracted from tool identification information; for example, the version number "M-2017.03-SP2" is identified from the path " / usr / eda / synopsys / vcs / M-2017.03-SP2". Simultaneously, the installation root directory of the module parsing tool, such as " / usr / eda / synopsys / vcs / M-2017.03-SP2", is used as a component boundary clue, defining an independent software component entity. All identified clues are organized into a structured version clue set, where each entry contains the component name, a specific version number, and its physical boundary path.

[0033] The second step is standardization to generate the fingerprint digest. First, the version clue set undergoes a standardized representation process. This process includes two actions: first, all component entries are sorted lexicographically by component name to ensure deterministic processing order; second, version numbers are formatted into a uniform paradigm, for example, "V2.1" and "v2.1.0" are uniformly processed into "2.1.0". After processing, all sorted and formatted components and their version information are concatenated into a single, standardized long string. Subsequently, a standard cryptographic hash algorithm, such as SHA-256, is used to calculate a 256-bit binary digest, i.e., the fingerprint digest. This digest is highly sensitive to any slight changes in the input environment, ensuring the uniqueness of the fingerprint.

[0034] The third step involves combining the encoding to generate the final environment fingerprint. This involves combining the fingerprint digest generated in the previous step with the runtime constraint information extracted from the environment requirements profile. The runtime constraint information is metadata describing the environment's operating hardware and operating system platform, such as the required CPU architecture (e.g., x86_64), the operating system kernel version range (e.g., RHEL7.x), and the minimum memory requirements. The combination encoding process is not a simple string concatenation but a structured encapsulation process. This process can be represented by a function to obtain the final generated environment fingerprint. ,have: ; in, The fingerprint digest is a 256-bit binary number, usually represented as a hexadecimal string; To convert structured data (objects / dictionaries) into strings; These are commonly used Base64 encoding functions; For the set of constraint information to run, for example cpu_arch is the CPU architecture, os_kernel is the operating system kernel version range, and min_memory is the minimum memory requirement (MB). , These represent the identity digest of the software stack and the hardware and operating system constraints of the runtime environment, respectively. The final generated environment fingerprint is a portable string containing the software stack identity and hardware platform requirements.

[0035] For example, the environment requirement profile for the "DSP_CORE_v2" static time-series analysis task generated in the previous step is used as input. The first step is to extract clues to generate a version clue set. Scanning the profile, using regular expressions from the version extraction rule base, the tool version clue "Q-2019.12-SP3" is successfully matched and extracted from the tool identification information / opt / synopsys / primetime / Q-2019.12-SP3 / bin / pt_shell. Simultaneously, the tool's installation root directory / opt / synopsys / primetime / Q-2019.12-SP3 is identified as a component boundary clue. Assuming the profile also contains another dependent tool, gcc, with the path / usr / bin / gcc-4.8.5, these clues are organized into a version clue set. The second step is normalization to generate a fingerprint digest. First, the version clue set is sorted lexicographically by component name, resulting in gcc first, followed by primetime. Next, the primetime version "Q-2019.12-SP3" and gcc version "4.8.5" are formatted, assuming they remain unchanged after standardization. Then, the formatted information is concatenated into a normalized long string: "component:gcc,version:4.8.5;component:primetime,version:Q-2019.12-SP3;". Subsequently, the SHA-256 hash algorithm is applied to this string to generate a 256-bit fingerprint digest D, such as "1a2b3c...". The third step involves combining the encodings to generate the final environmental fingerprint. Operational constraint information is extracted from the environmental requirement profile, such as... Then, the fingerprint digest is combined with runtime constraint information and encoded. This results in a portable environment fingerprint. Through standardization and hash digest processing, it is solidified into a highly sensitive and unique fingerprint digest. This is then combined with runtime constraints such as hardware and operating system constraints to generate a comprehensive environment fingerprint, improving the accuracy and reliability of environment migration and verification.

[0036] Based on the environmental fingerprint, dependency scanning and path parsing are performed on the construction nodes, and closure processing is performed to obtain the dependency closure. Optionally, obtaining the dependency closure includes: Based on the installation location of the environmental fingerprinting tool and the script entry location, an entry location result is generated; Dynamic link resolution and interpreter resolution are performed on the entry point location results to generate a dependency graph; The dependency graph is expanded for reachability and filled with missing items to generate a dependency closure.

[0037] Specifically, the module first parses the input environment fingerprint to extract tool identification information, such as the tool name "VCS" and version "M-2017.03-SP2". Then, the module queries a pre-configured tool inventory library, a database mapping logical tool names to physical installation locations, or performs a pattern-matching search in a set of preset root directories in the file system, such as " / opt / eda" or " / tools", to identify the tool's installation location. Simultaneously, the module analyzes typical environment setup scripts associated with the tool, such as "cshrc.vcs", to identify the script's entry point. A key parameter in this process is the tool search path list, typically containing 3-5 standard internal software deployment root directories. The final output is the entry point location result, a list of absolute paths containing all relevant executable files and top-level environment scripts.

[0038] The module iterates through each file path in the entry point location results. For binary executables or shared library files, the module performs dynamic link resolution, which is achieved in practice by calling system tools such as "ldd" or "readelf." This reads the file's ELF header information and extracts all shared library dependencies marked with the "NEEDED" field. For interpreted script files such as Tcl, Perl, or Shell scripts, the module performs interpreter resolution, employing a language-specific static code analyzer to scan the file content, identify, and extract instructions such as "source," "require," and "import" that import other files or modules. A key parameter in this process is the recursion depth of script resolution, typically set to 3-5 levels to prevent infinite loops in complex script calls. All identified dependencies are organized into a directed graph, i.e., a dependency graph, where nodes represent files and edges represent dependencies.

[0039] The dependency graph generated in the previous step is expanded using reachability. This is equivalent to performing a depth-first or breadth-first traversal of the graph, starting from the entry node. Whenever a new unprocessed node, i.e., a newly discovered dependency file, is encountered, the module recursively performs dynamic link resolution or interpreter resolution on that file, adding its dependencies as new nodes and edges to the graph. This process continues until all reachable nodes in the graph have been visited and resolved. Subsequently, the module performs missing item completion, comparing the target paths of all dependencies in the graph against a whitelist of system base libraries. This whitelist contains approximately 100-200 core operating system libraries, such as "libc.so.6," which are assumed to exist on the target node and therefore do not need to be packaged. All dependencies not in the whitelist and whose physical paths do not exist are marked as build errors. The dependency closure obtained from the entire closure build process is then defined. ,have: ; in, For dependent file nodes; This is a collection of all nodes or files that can be reached by dynamic linking or interpreter importing, starting from the entry node. This includes a whitelist of system base libraries, such as libc.so.6, and approximately 100–200 other core operating system libraries. For file n to actually exist in the file system, This indicates that the statement is true. The final dependency closure is a list containing all necessary non-system files. For example... Figure 2 As shown, this graph more realistically reflects the dependency closure construction process. The curves show that in the early stages of dependency resolution, i.e., recursion depths 1-3, the number of discovered dependency files increases explosively; as the resolution deepens, more and more dependencies are encountered repeatedly, and the growth rate of newly discovered dependencies slows down, eventually stabilizing. This aligns with the "long tail" and "network-centric" characteristics of real-world software dependencies. The gray area in the graph visually demonstrates the filtering effect of the system library whitelist, which removes a large number of low-level system libraries in the later stages of resolution, thereby optimizing the size of the final environment package.

[0040] For example, using the environment fingerprint of the "DSP_CORE_v2" task generated in the previous step as input, a dependency closure is generated on the build node. First, the environment fingerprint is parsed using `mvn` to extract the tool identifier information "primetime" and the version "Q-2019.12-SP3". Then, it is searched in the preset tool search path list. The search revealed a matching tool installation location in the ` / opt / eda / synopsys / primetime / Q-2019.12-SP3` directory. Analysis also revealed an environment setup script named `cshrc.pt` in this directory, which was identified as the script's entry point. These two paths together constituted the entry point location result. Next, the entry point location result was traversed. For the binary executable file ` / opt / eda / synopsys / primetime / Q-2019.12-SP3 / bin / pt_shell`, dynamic link analysis using the `ldd` command revealed its dependencies on `libtcl8.5.so` and `libsyn_base.so`. For the script file `cshrc.pt`, static analysis was used to interpret it, revealing the instruction `source / opt / synopsys / common / setup.csh`, thus identifying a dependency on the `setup.csh` file. These files and their dependencies were organized into a dependency graph. Finally, reachability expansion and missing item completion were performed on this dependency graph. Starting from pt_shell and cshrc.pt, newly discovered dependencies are recursively resolved, such as performing ldd resolution again on libsyn_base.so. Simultaneously, a whitelist of system base libraries is maintained, containing approximately 150 core libraries, such as libc.so.6 and libm.so.6. For the dependency closures obtained throughout the closure construction process, in this example, the set of nodes obtained after reachability expansion includes / opt / eda / synopsys / primetime / Q-2019.12-SP3 / lib / libsyn_base.so and / lib64 / libc.so.6, etc. During closure calculation, libsyn_base.so is not on the whitelist and exists in the file system. Therefore, it is included in the final dependency closure; while libc.so.6 is excluded because it is on the whitelist. The final dependency closure is a list of files containing all physically existing, non-operating system-based files required to run PrimeTime, such as pt_shell, cshrc.pt, and libsyn_base.so. By parsing the environment fingerprint, this method can accurately locate the tool entry point and, combined with dynamic linker resolution and interpreter resolution, systematically and automatically trace all runtime dependencies.

[0041] The dependent closures are subjected to conflict detection and sequential arrangement, and a build plan is generated by combining resource constraint information. The build plan includes a sequence of build steps and verification point information. Optionally, the step of performing conflict detection and sequencing of the dependent closures and generating a build plan in conjunction with resource constraint information includes: Version conflict identification and alternative candidate generation are performed on the dependent closure to obtain a conflict set and a candidate set; Based on the conflict set and the candidate set, conflict resolution is performed and component selection results are generated to obtain the resolved dependency closure. Perform topological sorting on the resolved dependency closures, and extract key verification nodes based on the environment requirement profile to generate verification point information; Perform topological sorting on the resolved dependency closures and insert the verification point information to generate a build plan.

[0042] Specifically, this method first performs conflict identification and candidate generation. It receives dependency closures as input, iterates through each file within them, and parses its metadata to identify the component and version number to which it belongs. A component mapping table is maintained, recording the processed components and their versions. When a new file is found to belong to a component already in the table but with a different version number, a version conflict is identified. For example, tool A depends on "libcrypto.so.1.0.0", while tool B depends on "libcrypto.so.1.1". All such conflicts are recorded in a conflict set. For each conflict, a pre-built component compatibility knowledge base is queried to generate a set of alternative candidates, containing intermediate versions or patch versions that may be compatible with all dependencies.

[0043] A conflict resolution algorithm is applied, which makes decisions based on a conflict set and a candidate set. This decision-making process can be guided by a cost optimization model, the objective of which is to minimize the risk and cost of introducing a new version. The optimization objective is to minimize the objective function. ,have: ; in, The importance weight of component v in the design task, with a value ranging from 0.1 to 1.0, is manually specified by experienced users or system administrators based on historical usage frequency and stability records; For component version v, the stability rating is as follows: ,in, This represents the number of known critical defects in version v. The number of days since version v was released; The number of build tasks using version v; The total number of build tasks using this component; To sum over the selected component version v. By solving this model, the lowest-cost candidate version is selected for each conflict, thus generating the component selection result. The dependency closure is then updated accordingly, resulting in a resolved dependency closure that is compatible with all versions.

[0044] Based on the task phase elements in the environmental requirements profile, core EDA tools, such as logic synthesizers or static timing analysis tools, are identified. For each identified core tool, the module extracts one or more lightweight smoke test scripts from a verification test case library. These scripts are designed to quickly verify the tool's basic functionality, such as executing the "tool_executable-version" command to check version output, or running a miniature design case that takes only 1-2 minutes. Finally, these test scripts and their execution conditions are encapsulated into structured verification point information.

[0045] A topological sort is performed on the resolved dependency closures. This is a standard graph algorithm that transforms the dependency graph into a linear sequence of nodes, ensuring that any component appears only after all its dependencies have been processed. This ordered sequence is then traversed, and verification steps are inserted into their appropriate positions based on the trigger conditions defined in the verification point information. For example, after all library files related to the static timing analysis tool have been sorted, verification commands for that tool are inserted. The resulting build plan is a well-defined queue of instructions that includes the order in which all files are retrieved and placed, interspersed with critical functional verification checkpoints.

[0046] For example, taking the dependency closure of the "DSP_CORE_v2" task as input, this closure not only contains a dependency on PrimeTimeQ-2019.12-SP3, but also, due to project requirements, a dependency on an internal inspection tool called superlint_v1. First, conflict identification is performed. While traversing the dependency closure, it is found that superlint_v1 depends on / usr / lib / openssl-1.0.0 / libcrypto.so. Version 1.0.0, while PrimeTime relies on its own / opt / synopsys / primetime / Q-2019. The error message "12-SP3 / lib / libcrypto.so.1.1" indicates a version conflict. The conflict is identified as `{component:"libcrypto.so", versions:{"1.0.0", "1.1"}}` and added to the conflict set. Simultaneously, a component compatibility knowledge base is consulted, and a tested compatible version, `libcrypto.so.1.1-patcheda`, provided by the IT department, is found as a candidate alternative. Conflict resolution is then performed. A cost optimization model is applied to evaluate the three versions. Assuming a PrimeTime importance weight of 0.9 and a superlint_v1 weight of 0.4, version 1.1 has a high stability rating of 0.95, version 1.0.0 has a low stability rating of 0.6, and candidate version 1.1-patcheda has a medium stability rating of 0.8. Version 1.1 usage rate is also considered. The usage rate was as high as 0.8, and as low as 0.05 for version 1.0.0. Calculations showed that libcrypto.so.1.1-patcheda had the lowest overall cost, so the component selection results were generated, determining that libcrypto.so.1.1-patcheda would be used, and the dependency closures were updated to obtain the resolved dependency closures. Then, based on the environment requirements profile, PrimeTime was identified as the core tool, and a smoke test script named check_pt_license.tcl was extracted from the verification test case library as verification point information. Finally, the resolved dependency closures were topologically sorted to generate a linear file processing sequence. In this sequence, the execution steps of check_pt_license.tcl were inserted after all PrimeTime-related libraries and binaries and before any scripts that depend on PrimeTime. The final output build plan is a detailed sequence of instructions, specifically "1. Copy libcrypto.so.1.1-patcheda to target... 2. Copy pt_shell to target... N. Execute check_pt_license.tcl...". By introducing verification points, health checks are seamlessly integrated into the build process, ensuring that the environment is fully functional at key nodes during the build process, thereby improving the success rate and reliability of environment builds.

[0047] According to the build plan, dependency acquisition, component assembly and entry mapping are performed to generate an environment package and generate environment proof information associated with the environment fingerprint; Optionally, generating the environment package and generating environment verification information associated with the environment fingerprint includes: According to the construction plan, the dependency closures are assembled in a hierarchical manner to generate a hierarchical structure, resulting in the environment package structure; Based on the entry mapping and library loading rules of the environment package structure generation tool, the environment package metadata is obtained; Perform digest signing and association recording on the environment package metadata and the environment fingerprint to generate environment proof information and encapsulate it to obtain the environment package.

[0048] Specifically, the process begins with layered assembly to obtain the environment package structure. This is done strictly according to the build step sequence defined in the build plan. The module first creates a temporary build root directory. Then, it iterates through each dependency fetching step in the build plan, retrieving files from their source locations and placing them in a target path under the build root directory, maintaining the relative directory structure of the files in the original environment. A key practice in this process is layered assembly, which places files into different layers based on the stability and shareability of components. For example, stable and universal base libraries such as "Tcl / Tk" are placed at the bottom layer, while frequently changing PDK libraries are placed at the top layer. This layered structure is typically represented in the project as different subdirectories, such as " / layers / base" and " / layers / tools". The final environment package structure is a directory tree whose content and organization are entirely determined by the build plan.

[0049] The system scans the existing hot environment package structure and automatically generates two types of key metadata. The first type is tool entry point mapping, which identifies all executable files within the package and creates symbolic links or startup scripts for them, centrally placing them in a unified entry directory such as " / entrypoints". This eliminates the need for users to know the specific location of tools within the package. The second type is library loading rules. Based on the distribution of shared libraries within the package, the module generates environment variable setting instructions to configure the dynamic linker loading path, such as generating "export LD_LIBRARY_PATH= / path / to / env_package / lib1: / path / to / "env_package / lib2". These mappings and rules are written to one or more metadata files, such as "manifest.json", forming complete environment package metadata.

[0050] The module performs a digest signing process on the environment package metadata and environment fingerprint. This process includes the following actions: First, the environment package metadata is serialized and concatenated with the environment fingerprint string. Then, an asymmetric encryption algorithm, such as RSA public-key encryption, is used to sign the concatenated data with a secret private key, generating a digital signature. This digital signature, the public key used for verification, and the environment fingerprint itself together constitute the environment verification information. Finally, the module packages and archives the hierarchically assembled complete directory tree (i.e., the environment package structure), environment package metadata, and environment verification information to generate the final environment package, such as a compressed tar archive or container image layer. This environment package possesses self-describing, tamper-proof, and verifiable characteristics, enabling secure distribution and reproduction of a completely consistent runtime context on any compatible execution node.

[0051] For example, strictly following the build plan generated in the previous step for the "DSP_CORE_v2" task, the environment package generation begins. First, layered assembly is performed to obtain the environment package structure. A temporary build root directory ` / tmp / build_root` is created. According to the build plan, it first retrieves the basic libraries such as Tcl / Tk 8.5 and the parsed libcrypto.so.1.1-patcheda from the source location and places them in the ` / tmp / build_root / layers / base` directory. Next, it retrieves all files of PrimeTime Q-2019.12-SP3, maintaining their relative path structure, and places them in ` / tmp / build_root / layers / tools / primetime_q-2019.12-sp3`. This forms a clear environment package structure. Then, the environment package metadata is generated. Scan the assembled directory tree and locate the executable file pt_shell under ... / layers / tools / primetime_q-2019.12-sp3 / bin / . Create a symbolic link named pt_shell for it in the / tmp / build_root / entrypoints / directory. Simultaneously, based on the location of library files in the base and tools layers, generate the library loading rule export LD_LIBRARY_PATH= / env / layers / base / lib: / The information from `env / layers / tools / primetime_q-2019.12-sp3 / lib` is written to the metadata file ` / tmp / build_root / manifest.json`. Finally, digest signing and encapsulation are performed. The contents of `manifest.json` are serialized and concatenated with the previously generated environment fingerprint string. Then, this concatenated data is signed using a secret RSA private key to generate a digital signature. This signature, the public key used for verification, and the environment fingerprint itself together constitute the environment proof information and are stored along with `manifest.json` in the ` / tmp / build_root / metadata / ` directory. Finally, the entire ` / tmp / build_root` directory is packaged and compressed into `dsp_core_v2_sta_env_rev1.tar.gz`, which is the final generated environment package containing all content and proof. Through layered assembly, this method creates a well-structured, easily managed, and updatable environment package structure. Automatically generated tool entry mappings and library loading rules simplify user operation, achieving self-contained and ready-to-use environments.

[0052] The environment package and the environment verification information are sent to the execution node and an injection configuration is generated. The injection configuration is used to establish a runtime context consistent with the environment package on the execution node. Optionally, the generation injection configuration includes: Obtain the node capability information and existing environment information of the execution node, and generate the node environment baseline; The differences between the node environment baseline and the environment package metadata are calculated to generate an injection difference set; Based on the injection difference set, path injection rules, variable injection rules, and entry redirection rules are generated to obtain the injection configuration and complete its distribution.

[0053] Specifically, the first step is to acquire node information to generate a node environment baseline. This is done by remotely executing a set of predefined probe commands to obtain the node's capabilities and current environment information. Node capability information includes static data at the hardware and system levels, such as CPU architecture (x86_64) and operating system version (CentOS 7.9). Current environment information includes dynamic context data, such as the current user's PATH environment variable value, the setting of LD_LIBRARY_PATH, and the actual paths of key system tools like "gcc" and "python" determined by the "which" command. This probe command set typically contains 15-25 commands. All collected information is integrated and normalized to form the node environment baseline, a set of key-value pairs describing the node's "current state."

[0054] Perform difference calculations to generate the injection difference set. The node environment baseline is compared with the environment package metadata. The environment package metadata defines the "target state" required for the environment package to run successfully; for example, it requires that PATH contain the package's tool entry directory and LD_LIBRARY_PATH contain the package's library directories. Difference calculation is an item-by-item comparison process. For example, the module compares the list of required library paths in the environment package metadata with the list of existing library paths in the node environment baseline, identifying paths that are present in the former but not in the latter. This process can be abstracted as an operation that yields the injection difference set. ,have: ; in, For configuration items, it represents a single element in the set, which represents a specific environment configuration entry; Configure the target state set for the environment package metadata definition; This sets the existing environment configurations for the target execution node. The final output injection difference set is a structured list of changes that clearly describes all add, delete, and modify operations required to achieve the target state.

[0055] Three core rules are generated based on the injected difference set. First, path injection rules: for paths in the difference set that need to be added to PATH or LD_LIBRARY_PATH, instructions in the form of "exportPATH= / path / to / package / bin:$PATH" are generated to ensure that paths within the package are searched first. Second, variable injection rules: for environment variables specific to the environment package, such as license server settings for EDA tools, instructions in the form of "exportVENDOR_LICENSE_FILE=..." are generated. Third, entry redirection rules: when a tool within the environment package has the same name as an existing tool on a node but needs to be used first, this rule implicitly redirects the entry by adjusting the PATH injection order. These three types of rules are combined into one or more shell script files to form the final injection configuration. This injection configuration, along with the environment package and environment verification information, is sent to the execution node, waiting to be activated when the task starts.

[0056] For example, the environment package dsp_core_v2_sta_env_rev1.tar.gz generated in the previous step, along with its environment verification information, is distributed to an execution node named grid-node-101. First, node information is obtained to generate a node environment baseline. A probe command set is remotely executed on grid-node-101, obtaining the node's capability information: CPU architecture x86_64, operating system version CentOS 7.9; and the existing environment information: PATH= / usr / local / bin: / usr / bin, LD_LIBRARY_PATH is not set. This information constitutes the node environment baseline. Next, difference calculations are performed to generate an injection difference set. The node environment baseline is compared with the target state defined in the environment package metadata manifest.json. The target state requires PATH to contain / env / entrypoints, and LD_LIBRARY_PATH to contain / env / layers / base / lib and / env / layers / tools / primetime_q-2019.12. -sp3 / lib. These are clearly not included in the current node's configuration B. This process can be represented by the formula above. The calculated injection difference set is... These are configuration items x that are present in the target state configuration set but not in baseline B. Finally, an injection configuration is generated based on the injection difference set. This generates a shell script named `activate_env.sh`. This script contains path injection rules, such as `export PATH=" / path / to / unpacked_env / entrypoints:$PATH"`; library path injection rules, such as `export LD_LIBRARY_PATH=" / path / to / unpacked_env / layers / base / lib: / path / to / unpacked_env / layers / tools / primetime_q-2019.12-sp3 / lib"`; and variable injection rules, such as the license server setting read from metadata, `export LM_LICENSE_FILE=27000@lic-server.mycorp.com`. This `activate_env.sh` script, as the final injection configuration, is stored on grid-node-101 along with the environment package for users to activate before starting the task. Instead of crudely overwriting or modifying the global environment of the execution node, this method generates a minimal, non-intrusive injection configuration through precise difference calculations. It can dynamically and on demand "inject" the necessary environment variables and paths for a specific task without affecting other tasks running on the node.

[0057] Based on the injection configuration, the design task is initiated and operational evidence is collected to generate an operational consistency report.

[0058] Optionally, generating the runtime consistency report includes: Based on the injection configuration, the actual parsing path of the tool, the actual library loading summary, and the variable expansion results of the collection and execution node are used to generate runtime evidence. The consistency of the operational evidence and the environmental proof information is compared to generate a consistency determination result. Based on the consistency determination results, difference entries and their impact ranges are generated, resulting in an operational consistency report.

[0059] Specifically, before the task starts, critical system calls are intercepted by injecting hook functions into the configuration or using techniques such as "LD_PRELOAD". During task execution, the following three types of information are collected in real time as runtime evidence: First, the actual parsing path of the tool; when the task calls an EDA tool, the absolute path of the executable file actually found and executed by the operating system is recorded by intercepting the "execve" system call. Second, the actual library loading digest; when a process loads a shared library, the absolute path of the loaded ".so" file is recorded by intercepting the "open" or "mmap" system calls, and a SHA-256 hash value is calculated as its digest. Third, variable expansion results; at critical stages of the task, the final expanded values ​​of all relevant environment variables are collected and recorded. The collected evidence is stored in a structured manner for subsequent analysis.

[0060] The runtime evidence is compared with the environment verification information. The environment verification information includes the expected tool path, the content hashes of all dependent libraries, and preset environment variables. The comparison performs the following operations: string matching between the actual tool parsing path and the expected path recorded in the environment verification; comparison between the actual library load digest and the corresponding library file hash value recorded in the environment verification; and comparison between the actual variable expansion results and the expected values. This comparison process can be described by a decision function, which determines the consistency of the comparison results. ,have: ; Where l represents the total number of comparison items; For the i-th comparison item, , To run the i-th element in the evidence set, For the i-th element in the set of environmental proof information, This indicates that the actual value equals the expected value. The final consistency determination result is a list containing all alignment items and their determination status. A value of 1 indicates a "MATCH" status, and a value of 0 indicates a "MISMATCH" status. For example, assuming there are 5 alignment items, the determination result would be: If the first, third, and fourth items are consistent, then the second and fifth items are inconsistent.

[0061] The module generates variance details to obtain an operational consistency report, iterates through the consistency determination result list, and filters out all entries with a status of "MISMATCH". For each variance entry, the module performs in-depth analysis to determine the scope of impact. For example, if a critical shared library version mismatches, the module queries the dependency graph to identify all tools that depend on that library and lists them as affected features. Finally, all variance entries, the expected and actual values ​​of each variance, and their potential scope of impact are integrated into a structured operational consistency report. This report is presented in a clear format, enabling engineers to quickly pinpoint the root causes of environmental inconsistencies and assess the potential risks they may pose to design outcomes.

[0062] For example, on the grid-node-101 node, the user first executes `source activate_env.sh` to activate the injection configuration, and then starts the static timing analysis task for "DSP_CORE_v2". During the task execution, runtime evidence is collected. By intercepting the `execve` system call, it records that when the task calls `pt_shell`, the operating system actually executes ` / proj / dsp_v2 / env / entrypoints / pt_shell`, which constitutes the actual parsing path of the tool. By intercepting the `open` system call, it records that the process loads ` / proj / dsp_v2 / env / layers / base / lib / libtcl8.5.so`, and immediately calculates its SHA-256 hash value, obtaining 'e3b0c4...' as the actual library load digest. Simultaneously, it collects the final expanded value of the environment variable `LM_LICENSE_FILE` as 27000@lic-server.mycorp.com. This information is collected as runtime evidence. Next, the runtime evidence is compared for consistency with the environment verification information. This comparison process can be described using a decision function. For the obtained consistency decision result, if we have three comparison items: a1 is the expected pt_shell path, a2 is the expected libtcl8.5.so hash, and a3 is the expected license variable value, then the running evidence e1, e2, and e3 correspond to them. If e1 equals a1 and e2 equals a2, but a global configuration file on the node forcibly redirects LM_LICENSE_FILE to another test server, causing e3 to not equal a3, then r1=1, r2=1, r3=0, and the final consistency decision result is R={1,1,0}. Finally, a runtime consistency report is generated based on this result. Traversing the result list, r3 is found to be MISMATCH. The report will generate a discrepancy entry, clearly indicating that the discrepancy is LM_LICENSE_FILE, with an expected value of 27000@lic-server.mycorp.com and an actual value of 27005@test-lic.mycorp.com. It will also analyze the scope of its impact, suggesting that it may prevent the acquisition of features from the official version of the tool, thus affecting the accuracy of time-series analysis. This method implements "runtime forensics" of the actual task execution, providing a powerful runtime verification mechanism. It goes beyond static environment packaging, delving into the dynamic process of task execution, and can accurately capture and report any deviations in environment configuration at the last moment.

[0063] Optionally, the method further includes: Extract the discrepancy entries from the operational consistency report and perform attribution classification to generate discrepancy attribution results; Based on the difference attribution results, the environment package version is selected and a rollback instruction is generated to obtain the rollback execution plan; Execute the rollback execution plan and regenerate the runtime evidence to obtain the rollback verification results and update the environment requirement profile.

[0064] Specifically, the process begins by extracting all discrepancy entries marked "MISMATCH" from the runtime consistency report. Then, a rule-based attribution engine analyzes each discrepancy. This engine has a built-in knowledge base of 20-40 rules that map discrepancy patterns to root causes. For example, rule one attributes a discrepancy to "HOST_INTERFERENCE" (host environment interference) if the library's actual load path points to a directory like " / usr / lib64" instead of within the environment package. Rule two attributes a discrepancy to "PACKAGE_CORRUPTION" (packet transfer or decompression error) if the loaded library file comes from the environment package but its hash digest does not match the environment proof information. Rule three attributes a discrepancy to "INCOMPLETE_CLOSURE" (incomplete dependency closure build) if an expected library file is not found at runtime. Finally, a specific classification label is attached to each discrepancy entry, resulting in a structured discrepancy attribution.

[0065] The system receives the discrepancy attribution results as input for decision-making. Based on the attribution results, it selects recovery actions, specifically in two scenarios: If the attribution result is primarily "HOST_INTERFERENCE", then no rollback operation is performed on the environment package. Recovery actions include generating environment isolation optimization suggestions, such as modifying the injection configuration to add stricter path isolation rules, like using container technology or modifying the injection order of LD_LIBRARY_PATH, and outputting these suggestions to the operations log for engineer review. Simultaneously, the current task execution record is marked, prompting the user to check for host-level global configuration conflicts. No rollback execution plan is generated. If the attribution result is "PACKAGE_CORRUPTION" (package transmission error) or "INCOMPLETE_CLOSURE" (incomplete dependency closure), then the rollback process is initiated. An environment package repository is queried, selecting the previous environment package version marked "STABLE". Subsequently, a series of rollback instructions are automatically generated, including: stopping the current task, cleaning up the existing environment package directory on the execution node, downloading and deploying the selected old version environment package from the repository, and reapplying the injection configuration of that version. These instructions are combined into an atomic script, namely, a rollback execution plan.

[0066] Execute the rollback execution plan on the execution node. After successfully deploying the rollback environment, the original design task is automatically restarted. During task execution, new runtime evidence is collected again using the method described above, and a new runtime consistency report is generated. This report is the rollback verification result. Ideally, this report should no longer contain any discrepancies. Most importantly, an action to update the environment requirements profile is performed. If the original failure was attributed to "INCOMPLETE_CLOSURE," the missing dependency will be automatically added or corrected as a new entry to the original environment requirements profile associated with this design task. This update ensures that all future build requests based on this profile will include this previously omitted dependency, thereby reducing the recurrence of similar errors. Figure 3 As shown, the overall trend of the curve is significantly downward, indicating that as the iteration progresses, the inconsistency rate of the environment is effectively controlled and continuously reduced. The figure shows that in the 4th iteration, the inconsistency rate experienced a slight rebound, which simulates the "fix regression" phenomenon commonly seen in engineering practice. That is, a fix made to solve a problem, such as a low version of library A, may unintentionally introduce a new problem. In the later stages of the iteration, the curve tends to flatten and remain at a very low level, indicating that most environmental problems have been solved and a highly stable and deterministic state has been reached. At this time, fine-tuning is still being done on some extremely hidden or sporadic problems, such as the small fluctuations in the 9th iteration.

[0067] For example, the runtime consistency report generated in the previous step, which contains a mismatch in the LM_LICENSE_FILE variable, is used as input. First, attribution classification is performed. The attribution engine extracts the discrepancy entry, analyzes it, and finds that an environment variable is being overridden by an external setting. Based on its built-in rules, the root cause of this discrepancy is classified as "HOST_INTERFERENCE," i.e., host environment interference, generating a discrepancy attribution result. Next, a recovery action is selected based on the attribution result. Since the attribution is host interference rather than a problem with the environment package itself, the decision is not to perform a rollback of the entire package. Instead, it may suggest that the user check or contact the system administrator. To illustrate the rollback more completely, we assume another scenario where the report shows a hash digest mismatch in a library file libsyn_base.so, with an attribution result of "PACKAGE_CORRUPTION." In this case, the rollback process is initiated, the environment package version repository is queried, and a stable version prior to the current rev1 version, dsp_core_v2_sta_env_rev0.tar.gz, is found. A rollback execution plan is then generated, consisting of a script containing instructions such as `rm -rf / proj / dsp_v2 / env / *` and `tar -xzf ... / dsp_core_v2_sta_env_rev0.tar.gz -C / proj / dsp_v2 / env`. After the plan is executed, the rev0 version environment is deployed. The task is restarted, and new runtime evidence is collected. The generated rollback verification results show that all comparisons are "MATCH", proving that the rollback was successful. Finally, a critical profile update is performed. Consider another scenario: if the initial failure was due to PrimeTime crashing while reporting graphs because of the missing libpng12.so, attributed to "INCOMPLETE_CLOSURE", after manually locating and resolving this issue, an interface is provided to permanently update the missing libpng12.so dependency as a new entry in the original environment requirement profile associated with the "DSP_CORE_v2 STA" task. This method constructs a complete closed-loop self-healing system of "detection, attribution, repair, and learning". It can not only identify problems, but also pinpoint their root causes and take appropriate recovery strategies based on the reasons.

[0068] Based on the same inventive concept, such as Figure 4 As shown, the present invention also provides a basic platform construction system for a chip design EDA environment, the system comprising: The profile generation module is used to obtain and parse design task description information and tool call records to generate an environmental requirement profile; The fingerprint generation module is used to extract tool identification information, dependency type information and runtime constraint information from the environmental requirement profile and perform normalization processing to generate an environmental fingerprint. The closure construction module is used to perform dependency scanning and path parsing on the construction nodes based on the environment fingerprint, and to perform closure processing to obtain dependency closures; The plan generation module is used to perform conflict detection and sequence arrangement on the dependency closures and generate a build plan in combination with resource constraint information. The build plan includes a sequence of build steps and verification point information. The environment packaging module is used to perform dependency acquisition, component assembly and entry mapping according to the build plan, generate an environment package and generate environment proof information associated with the environment fingerprint; An injection delivery module is used to deliver the environment package and the environment verification information to the execution node and generate an injection configuration. The injection configuration is used to establish a runtime context consistent with the environment package on the execution node. The verification report module is used to initiate the design task based on the injection configuration, collect operational evidence, and generate an operational consistency report.

[0069] It should be noted that the electrical connections between the various units described above do not necessarily represent direct or indirect connections. Any indirect connection method can be applied to the embodiments of the present invention as long as it achieves the purpose of the present invention. The above descriptions are merely exemplary embodiments of the present invention and should not be construed as limiting the scope of the present invention.

[0070] All equivalent changes and modifications made in accordance with the teachings of this invention are still within the scope of this invention. Other embodiments of the invention will be readily apparent to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or conventional techniques in the art not described herein.

Claims

1. A method for constructing a basic platform for a chip design EDA environment, characterized in that, The method includes: Obtain and parse design task description information and tool call records to generate an environment requirement profile; Extract tool identification information, dependency type information, and runtime constraint information from the environmental requirement profile and perform normalization processing to generate an environmental fingerprint; Based on the environmental fingerprint, dependency scanning and path parsing are performed on the construction nodes, and closure processing is performed to obtain the dependency closure. The dependent closures are subjected to conflict detection and sequential arrangement, and a build plan is generated by combining resource constraint information. The build plan includes a sequence of build steps and verification point information. According to the build plan, dependency acquisition, component assembly and entry mapping are performed to generate an environment package and generate environment proof information associated with the environment fingerprint; The environment package and the environment verification information are sent to the execution node and an injection configuration is generated. The injection configuration is used to establish a runtime context consistent with the environment package on the execution node. Based on the injection configuration, the design task is initiated and operational evidence is collected to generate an operational consistency report.

2. The method for constructing a basic platform for a chip design EDA environment according to claim 1, characterized in that, The generated environment requirements profile includes: Obtain task phase information and input / output path information from the design task description information, and generate task phase elements; Obtain tool entry information and parameter expansion information from tool call records to generate call behavior elements; By integrating the task stage elements and the invocation behavior elements and annotating the dependency types, an environment requirement profile is generated.

3. The method for constructing a basic platform for a chip design EDA environment according to claim 1, characterized in that, The generated environment fingerprint includes: Extract tool version clues and component boundary clues from the environmental requirement profile to generate a version clue set; The set of version clues is represented in a consistent manner and a summary is generated to obtain a fingerprint summary; The fingerprint digest is combined with the operational constraint information and encoded to generate an environmental fingerprint.

4. The method for constructing a basic platform for a chip design EDA environment according to claim 1, characterized in that, The obtained dependency closure includes: Based on the installation location of the environmental fingerprinting tool and the script entry location, an entry location result is generated; Dynamic link resolution and interpreter resolution are performed on the entry point location results to generate a dependency graph; The dependency graph is expanded for reachability and filled with missing items to generate a dependency closure.

5. The method for constructing a basic platform for a chip design EDA environment according to claim 1, characterized in that, The step of performing conflict detection and sequence arrangement of the dependent closures and generating a build plan in conjunction with resource constraint information includes: Version conflict identification and alternative candidate generation are performed on the dependent closure to obtain a conflict set and a candidate set; Based on the conflict set and the candidate set, conflict resolution is performed and component selection results are generated to obtain the resolved dependency closure. Perform topological sorting on the resolved dependency closures, and extract key verification nodes based on the environment requirement profile to generate verification point information; Perform topological sorting on the resolved dependency closures and insert the verification point information to generate a build plan.

6. The method for constructing a basic platform for a chip design EDA environment according to claim 1, characterized in that, The process of generating an environment package and generating environment verification information associated with the environment fingerprint includes: According to the construction plan, the dependency closures are assembled in a hierarchical manner to generate a hierarchical structure, resulting in the environment package structure; Based on the entry mapping and library loading rules of the environment package structure generation tool, the environment package metadata is obtained; Perform digest signing and association recording on the environment package metadata and the environment fingerprint to generate environment proof information and encapsulate it to obtain the environment package.

7. The method for constructing a basic platform for a chip design EDA environment according to claim 1, characterized in that, The injection configuration includes: Obtain the node capability information and existing environment information of the execution node, and generate the node environment baseline; The differences between the node environment baseline and the environment package metadata are calculated to generate an injection difference set; Based on the injection difference set, path injection rules, variable injection rules, and entry redirection rules are generated to obtain the injection configuration and complete its distribution.

8. The method for constructing a basic platform for a chip design EDA environment according to claim 1, characterized in that, The generated runtime consistency report includes: Based on the injection configuration, the actual parsing path of the tool, the actual library loading summary, and the variable expansion results of the collection and execution node are used to generate runtime evidence. The consistency of the operational evidence and the environmental proof information is compared to generate a consistency determination result. Based on the consistency determination results, difference entries and their impact ranges are generated, resulting in an operational consistency report.

9. The method for constructing a basic platform for a chip design EDA environment according to claim 8, characterized in that, The method further includes: Extract the discrepancy entries from the operational consistency report and perform attribution classification to generate discrepancy attribution results; Based on the difference attribution results, the environment package version is selected and a rollback instruction is generated to obtain the rollback execution plan; Execute the rollback execution plan and regenerate the runtime evidence to obtain the rollback verification results and update the environment requirement profile.

10. A basic platform construction system for a chip design EDA environment, applied to the basic platform construction method for a chip design EDA environment as described in any one of claims 1-9, characterized in that, The system includes: The profile generation module is used to obtain and parse design task description information and tool call records to generate an environmental requirement profile; The fingerprint generation module is used to extract tool identification information, dependency type information and runtime constraint information from the environmental requirement profile and perform normalization processing to generate an environmental fingerprint. The closure construction module is used to perform dependency scanning and path parsing on the construction nodes based on the environment fingerprint, and to perform closure processing to obtain dependency closures; The plan generation module is used to perform conflict detection and sequence arrangement on the dependency closures and generate a build plan in combination with resource constraint information. The build plan includes a sequence of build steps and verification point information. The environment packaging module is used to perform dependency acquisition, component assembly and entry mapping according to the build plan, generate an environment package and generate environment proof information associated with the environment fingerprint; An injection delivery module is used to deliver the environment package and the environment verification information to the execution node and generate an injection configuration. The injection configuration is used to establish a runtime context consistent with the environment package on the execution node. The verification report module is used to initiate the design task based on the injection configuration, collect operational evidence, and generate an operational consistency report.

Images