Flow control method, device and equipment for integrated circuit design, and storage medium

Abstract

The present disclosure provides a flow control method, device and equipment for integrated circuit design and storage medium, and belongs to the technical field of integrated circuit design. The method comprises the following steps: determining the execution weight of a plurality of verification tasks in a current design stage according to a preset correlation rule; based on the execution weight, screening a target verification task from the plurality of verification tasks, and marking the target verification task as an enabled state. The most concerned target verification task in the corresponding design stage can be determined, and the number of invalid EDA tool running times is reduced.

Description

Technical Field

[0001] This disclosure relates to the field of integrated circuit design technology, and in particular to a process control method, apparatus, device and storage medium for integrated circuit design. Background Technology

[0002] In the field of integrated circuit design, with the continuous increase in chip complexity, the Design for Testability (DFT) process has become a critical step in ensuring chip quality and reliability. Modern chip projects typically involve multiple design modules, multiple verification tasks (such as test circuit insertion, simulation, and formal verification), and multiple milestone nodes (such as RTL35, RTL50, RTL100, etc.). These verification tasks need to be executed dynamically at different design stages to match project schedules and resource constraints.

[0003] In the existing technology, the process control and management of these verification tasks mainly rely on manual operation by engineers. Engineers usually need to manually determine which verification tasks must be performed based on the specific stage of the current project, their personal experience, or by referring to static project documents, and then manually write or adjust the corresponding script files to drive the Electronic Design Automation (EDA) tools.

[0004] However, this traditional manual management method has many drawbacks. First, as the project scales up, the number of modules and tasks involved grows exponentially, making the manual selection and configuration of tasks extremely labor-intensive and prone to errors, easily leading to the omission of key verification steps or incorrect parameter configuration. Second, this method relies too heavily on the individual experience of engineers; different engineers may have differing understandings of the process, making it difficult to guarantee the consistency and standardization of the design process.

[0005] Therefore, there is an urgent need for a method that can automate the management of verification task execution in order to improve efficiency and reduce reliance on human experience. Summary of the Invention

[0006] This disclosure provides a process control method, apparatus, device, and storage medium for integrated circuit design; it can determine the most important target verification tasks at different design stages, reducing the number of unnecessary EDA tool runs.

[0007] The technical solution disclosed herein is implemented as follows:

[0008] Firstly, this disclosure provides a process control method for integrated circuit design. The method includes: determining the execution weights of multiple verification tasks in the current design stage according to preset association rules; selecting a target verification task from the multiple verification tasks based on the execution weights, and marking the target verification task as enabled. Determining the execution weights of each verification task in the current design stage through preset association rules transforms the implicit experience of chip design experts regarding what to do at what stage into quantifiable rules that can be processed by a computer. Furthermore, selecting the target verification task that is of most concern in the current design stage reduces the number of ineffective EDA tool runs and saves computational resources. In addition, marking only the target verification task as enabled also avoids user errors.

[0009] In some embodiments, the association rule is a mapping matrix, which includes the execution weights of each verification task at different design stages. Based on the execution weights, the target verification task is selected from multiple verification tasks, including: querying the mapping matrix to obtain the execution weights of each verification task at the current design stage; and identifying verification tasks with execution weights greater than or equal to the enable threshold as target verification tasks. By using the mapping matrix, reliance on human experience is reduced, avoiding missed tests (missing high-weight tasks) or resource waste (mistakenly selecting low-weight tasks) due to human error, and ensuring the consistency and standardization of verification processes across different projects.

[0010] In some embodiments, the process control method for integrated circuit design further includes: extracting the historical failure rate and defect detection efficiency of each verification task at the same design stage from historical projects with a similarity higher than a similarity threshold to the current integrated circuit project; determining the change rate between the code of the verification task and the corresponding previous version of the code; and adjusting the execution weight of each verification task based on the historical failure rate, defect detection efficiency, and change rate. By introducing the historical failure rate and code change rate, high-risk areas that need to be verified are identified, and resources are concentrated for verification. This not only avoids ineffective repeated verification of stable modules, thereby saving computing power, but also can keenly capture potential risk points, ensuring that the most likely problems are discovered first within a limited time, thereby significantly improving the efficiency and quality of verification.

[0011] In some embodiments, the process control method for integrated circuit design further includes: determining an enable threshold for the current design stage based on the maturity level of the current design stage and / or the current load status of computing resources. The dynamic enable threshold adjustment mechanism enables adaptive process control. Adjustments based on maturity level conform to the objective laws of chip development, effectively balancing progress and quality; adjustments based on resource load achieve optimal allocation of computing resources, avoiding congestion caused by resource contention and ensuring the priority execution of critical verification tasks.

[0012] In some embodiments, the process control method for integrated circuit design further includes: responding to a trigger instruction for a target verification task, generating control instructions adapted to an electronic design automation (EDA) tool based on preset configuration parameters; calling the EDA tool to execute the control instructions and monitoring the log files output by the EDA tool during execution; parsing the feature information in the log files and updating the execution status of the target verification task in real time based on the parsing results. Generating scripts based on templates and parameters eliminates the risk of syntax errors (such as spelling errors or missing paths) caused by manually writing scripts, ensuring the consistency and standardization of the execution of all target verification tasks. Furthermore, by monitoring log features in real time, the originally black-box EDA execution process becomes transparent and visible. In large-scale integrated circuit designs, there may be hundreds of concurrent verification tasks, and it is impossible for humans to monitor every execution window in real time. The state machine mechanism in this embodiment can automatically capture anomalies and provide intuitive feedback through color, allowing engineers to intuitively grasp the project's health status, greatly reducing monitoring costs and shortening the cycle from problem discovery to problem resolution.

[0013] In some embodiments, in response to a trigger command for a target verification task, control commands adapted to the electronic design automation (EDA) tool are generated based on preset configuration parameters. These commands include: obtaining a script template corresponding to the target verification task; reading the design environment parameters of the current integrated circuit project and the configuration parameters of the target verification task; and filling the script template with the design environment parameters and configuration parameters to generate a script file and a command-line statement to start the EDA tool. The standardized design of the script template ensures the consistency and compatibility of the generated script files, avoiding syntax errors and logical inconsistencies caused by manually writing scripts. The automatic acquisition and filling of design environment parameters and task configuration parameters enables automated script file generation, significantly reducing manual operations by users and improving task execution efficiency. The automated generation of command-line statements simplifies the EDA tool's calling process, eliminating the need for users to manually input complex command-line instructions.

[0014] In some embodiments, the feature information in the log file is parsed, and the execution status of the target verification task is updated in real time based on the parsing results. This includes: determining the execution status as script generation if a corresponding script file exists in the working directory of the EDA tool; determining the execution status as running if the log file is detected to be being updated; determining the execution status as failed if an error keyword is matched in the log file; and determining the execution status as passed if no error keyword is matched in the log file, and / or a success keyword is matched. The status judgment logic based on log file feature information enables automated and real-time monitoring of the verification task execution status, eliminating the need for manual log file checks and significantly reducing operational complexity. The classification of error and success keywords improves the accuracy and specificity of status judgment, enabling rapid identification of different types of task execution results. The extraction and display of error messages provide effective support for users to quickly locate problems, improving debugging efficiency. Color coding for different statuses allows users to intuitively and quickly identify the task execution status, enhancing the user experience.

[0015] In some embodiments, the process control method for this integrated circuit design further includes: based on the received debugging instructions for the target verification task, changing the execution mode to interactive debugging mode and opening an interactive terminal window to allow the user to input debugging commands into the EDA tool or invoke waveform viewing tools. This debugging environment greatly reduces the barrier for engineers to manually set up a debugging environment.

[0016] In some embodiments, in interactive debugging mode, if the target verification task is of the circuit insertion type, the script is executed in the interactive terminal window and the tool remains running after execution; if the target verification task is of the formal verification type and a historical verification session file exists in the corresponding working directory, the session file is loaded for debugging. In this embodiment, for target verification tasks of the circuit insertion type, process keep-alive avoids repeated loading and releasing of netlist data, thus reducing the response time of debugging queries. For target verification tasks of the formal verification type, loading the session file reuses historical calculation results, avoiding repeated calculations of known logic proof processes, greatly saving expensive EDA computing power. This interactive debugging mode significantly improves the iteration speed of the chip verification process, thereby shortening the chip development cycle.

[0017] In some embodiments, the process control method for the integrated circuit design further includes: displaying multiple verification tasks in a matrix form on a visual interface; rendering each cell in the matrix with different colors or graphics according to the execution weight and execution status, wherein different colors correspond to the states of disabled, selected, script generated, running, passed, and failed, respectively. Thus, the user can intuitively determine the status of the target verification task based on the displayed colors.

[0018] In a second aspect, this disclosure provides a process control device for integrated circuit design, comprising: a determination part and a screening and marking part; the determination part is configured to determine the execution weights of multiple verification tasks in the current design stage according to preset association rules; the screening and marking part is configured to screen out a target verification task from the multiple verification tasks based on the execution weights and mark the target verification task as an enabled state.

[0019] Thirdly, this disclosure provides an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the flow control method for integrated circuit design as described in the first aspect.

[0020] Fourthly, this disclosure provides a computer-readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the flow control method for integrated circuit design as described in the first aspect.

[0021] Fifthly, this disclosure provides a computer program product, wherein the computer program product includes a computer program or instructions, which, when run on a processor, cause the processor to execute the computer program or instructions to implement the steps of the flow control method for integrated circuit design as described in the first aspect.

[0022] In a sixth aspect, this disclosure provides a chip including a processor and a communication interface coupled to the processor, the processor being used to run programs or instructions to implement the flow control method for integrated circuit design as described in the first aspect.

[0023] This disclosure provides a process control method, apparatus, device, and storage medium for integrated circuit design. It determines the execution weight of each verification task in the current design stage through preset association rules, that is, it makes explicit the implicit experience knowledge of chip design experts about what to do at what stage into quantitative rules that can be processed by computers. Furthermore, it selects the target verification tasks that are of most concern in the current design stage, reducing the number of invalid EDA tool runs and saving computing resources. In addition, only marking the target verification tasks as enabled can also avoid user misoperation. Attached Figure Description

[0024] Figure 1 This disclosure provides a system architecture diagram for a process control method in integrated circuit design.

[0025] Figure 2 This is a flowchart illustrating a process control method for integrated circuit design provided in this disclosure.

[0026] Figure 3 A schematic diagram of the verification task with different enable states provided in this disclosure.

[0027] Figure 4 A flowchart illustrating another process control method for integrated circuit design provided in this disclosure.

[0028] Figure 5 This is a flowchart illustrating the execution phase of the target verification task provided in this disclosure.

[0029] Figure 6 A schematic diagram of the visual interface for the verification task provided in this disclosure.

[0030] Figure 7 This is a schematic diagram of the task configuration interface provided in this disclosure.

[0031] Figure 8 This is a schematic diagram showing the overall health of the regression list in the aggregated view provided in this disclosure.

[0032] Figure 9 This disclosure provides a structural block diagram of a process control device for integrated circuit design.

[0033] Figure 10 This is a schematic diagram of the hardware structure of an electronic device provided in this disclosure. Detailed Implementation

[0034] The technical solutions in the embodiments of this disclosure will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure are within the scope of protection of this disclosure.

[0035] To better understand the integrated circuit design process control method provided in this application, the system architecture to which this method is applicable is first introduced. The method proposed in this application is typically integrated into an enterprise-level DFT (Design for Components) end-to-end management software tool, which aims to solve the challenges of resource allocation and progress monitoring when multiple tasks are executed concurrently.

[0036] Please see Figure 1 , Figure 1A system architecture diagram of the integrated circuit design flow control method provided in the embodiments of this application. (See diagram below.) Figure 1 As shown, the system architecture mainly includes: user terminal 100, process control server 200, computing cluster 300 and shared storage system 400.

[0037] User terminal 100 serves as the entry point for DFT engineers to interact with the process management system. User terminal 100 runs a graphical user interface (GUI), providing task scheduling, regression testing, and debugging interfaces. Engineers use the GUI to input the current design project name, select the current design milestone, and issue execution commands.

[0038] The process control server 200 is used for the calculation and scheduling of core logic. Internally, the process control server 200 includes functional modules such as a resource allocation engine, script generator, and log parser. In response to a configuration request received from the user terminal 100, it calculates the task weight according to a built-in algorithm, generates a script, and delivers the verification task to the backend computing cluster 300.

[0039] Computing cluster 300 typically consists of high-performance servers equipped with various EDA tools (such as Synopsys Design Compiler, Tessent, VCS, etc.). Computing cluster 300 is responsible for executing DFT verification tasks distributed by process control server 200, including computationally intensive operations such as logic synthesis, circuit insertion, and simulation verification.

[0040] Shared storage system 400 stores the project's Register-Transfer Level (RTL) code, generated script files, EDA tool output log files, waveform files, and netlists. Process control server 200 accesses this shared storage system 400 to read changes in the log files in real time and update the status of the verification tasks.

[0041] The method in this embodiment mainly runs in the process control server 200, and achieves fine-grained control over the DFT process through interaction with the user terminal 100 and the computing cluster 300.

[0042] The process control method for integrated circuit design provided in this disclosure will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0043] like Figure 2 As shown, the method may include the following steps S201 and S202.

[0044] In step S201, the execution weights of multiple verification tasks in the current design phase are determined according to preset association rules.

[0045] First, determine the current design phase of the integrated circuit project. An integrated circuit project refers to a specific chip development project, encompassing hundreds or thousands of functional modules. The design phase refers to a time point or status marker used to define the project's current maturity level; it is also known as a milestone. For example, design phases may include, but are not limited to, RTL0 (initial version of register-transfer level code), RTL50 (code development more than halfway complete, major functional modules integrated), RTL90 (code nearing freeze, functionality largely complete), RTL100 (code completely frozen, ready to enter back-end physical design), and tape-out (TO).

[0046] Specifically, the current design phase can be determined by receiving active user input through a GUI; alternatively, it can be determined by communicating with a version control system (such as Git or SVN) to automatically read the tag or branch information of the current code repository.

[0047] A verification task refers to the specific technical operations that need to be performed on a particular design object. A verification task is usually defined by a design phase (Milestone), a design module (Design), and an execution step (Step). For example, the scan chain insertion check performed on the CPU module in the RTL50 phase is a specific verification task.

[0048] Association rules are logical criteria pre-stored in a system database or configuration file, including the importance or necessity of different verification steps at different lifecycle stages of an integrated circuit project. Execution weight is a quantified numerical metric used to characterize the degree of necessity. For example, execution weight can be set as a floating-point number between 0 and 1, where 0 represents no execution required, 1 represents mandatory execution, and intermediate values ​​represent recommended or optional execution.

[0049] Specifically, all verification tasks are traversed, and the current design stage is used as the index key to query the preset association rules and determine the execution weight of each verification task. Taking a specific DFT flow as an example: assuming the current design stage is RTL35, the association rules specify that the focus at this stage is on evaluating the design area and basic connectivity. Therefore, DFT insertion type execution steps are assigned a high weight (e.g., 0.9). For full-chip timing gate simulation type execution steps, since the netlist has not yet been generated or the timing has not yet converged, executing this verification task is meaningless and highly prone to failure; therefore, it is assigned a very low execution weight (e.g., 0.0). Conversely, if the current stage is RTL, full-chip timing gate simulation is assigned the highest execution weight (e.g., 1.0), because this is a mandatory requirement before tape-out. In this way, abstract engineering experience is transformed into numerical weights that can be processed by a computer.

[0050] In step S202, based on the execution weight, the target verification task is selected from multiple verification tasks and marked as enabled.

[0051] Specifically, based on the established decision-making logic, target verification tasks are selected from the verification tasks. For example, an enable threshold is set, and the execution weight of each determined verification task is compared with this enable threshold. If the execution weight is greater than or equal to the enable threshold, the verification task is determined to be a target verification task, meaning it is a verification task that should be focused on and executed in the current design phase. Simultaneously, the status attribute of the target verification task in the database or memory object is marked as enabled.

[0052] The enabled state is a logical switch that determines whether a target verification task is eligible to be invoked by subsequent processes. On the GUI interface, verification tasks in the enabled state are usually presented to the user in an interactive form (such as highlighted or clickable checkboxes); while tasks not marked as enabled are locked or hidden to prevent users from accidentally triggering invalid tasks at the wrong time, thereby saving computing resources (such as CPU time and memory usage).

[0053] like Figure 3 The diagram illustrates verification tasks in different enabled states, with the current design stage at RTL50. Execution steps are used as column indices, and design modules as row indices. The intersection of each row and column represents a verification task. The diagram uses execution steps a through f as an example, and design modules 1 through 6 as an example. White-filled cells correspond to the target verification task, indicating an enabled state; white fill signifies that the user is allowed to select it. Dotted-filled cells correspond to disabled verification tasks, indicating that the user is not allowed to select them; in actual display, dotted fill is represented by gray.

[0054] In this embodiment, the execution weight of each verification task in the current design stage is determined by a preset association rule. This means that the implicit experience knowledge of chip design experts about what to do at what stage is made explicit into quantitative rules that can be processed by a computer. Furthermore, the target verification tasks that are of most concern in the current design stage are selected, which reduces the number of invalid EDA tool runs and saves computing resources. In addition, only marking the target verification tasks as enabled can also avoid user misoperation.

[0055] In some embodiments, the association rule is a mapping matrix that includes the execution weights of each verification task at different design stages; such as Figure 4 As shown, the process control method for this integrated circuit design includes the following steps S401 to S403.

[0056] In step S401, the execution weights of multiple verification tasks in the current design phase are determined based on the mapping matrix.

[0057] This mapping matrix is ​​a multi-dimensional data structure. Its rows can represent various types of verification tasks, such as DFT circuit insertion, scan chain verification, in-memory built-in self-test (MBIST), and formal verification. The columns can represent various design phases of the project, such as RTL0, RTL50, RTL90, and TO. Each cell in the mapping matrix stores a value, which is the execution weight of the verification task at that design phase.

[0058] For example, one row of data in the mapping matrix is: Task type, testability design insertion; RTL0, execution weight 0.0; RTL50, execution weight 1.0; RTL 100, execution weight 1.0.

[0059] The execution weights are not fixed static values, but can change dynamically. Specifically, the system maintains a historical project database, which stores the execution records of historical projects. When determining the execution weight of the current verification task, a similarity matching is first performed, filtering historical projects from the historical project database that have a similarity higher than the similarity threshold with the current integrated circuit project (e.g., the same process node, similar chip type).

[0060] Based on data from similar historical projects, extract the historical failure rate of the current verification task at the same design stage (e.g., RTL50). The historical failure rate refers to the probability that the verification task has failed in the past; a high failure rate indicates that the design parts involved in the verification task are prone to errors and have a higher risk. Additionally, obtain the differences between the current integrated circuit project's code and the previous version to determine the change rate of the design modules covered by the verification task. The change rate can be measured by the number of lines of code changed or the proportion of changed files.

[0061] Using the historical failure rate and change rate determined above, the execution weight in the mapping matrix is ​​determined. For example, execution weight = original execution weight × (1 + a × historical failure rate + b × change rate), where a and b are preset adjustment coefficients.

[0062] As mentioned above, if a verification task has a high historical failure rate or a high current code change rate, its final weight will increase significantly, even exceeding its original execution weight. This means that verification tasks that originally had a low execution weight in the matrix (e.g., 0.4, below the enable threshold of 0.5) may be dynamically promoted to target verification tasks (with an execution weight of 0.6 > 0.5) due to their high risk. Conversely, if a design module's code remains unchanged and has a stable history, its execution weight may be reduced, thus filtering it out.

[0063] By incorporating historical failure rates and code change rates, high-risk areas requiring verification are identified, and resources are concentrated on verifying them. This not only avoids ineffective and repetitive verification of stable modules, thus saving computing power, but also enables the keen detection of potential risks, ensuring that the most likely problems are identified first within a limited timeframe, thereby significantly improving the efficiency and quality of verification.

[0064] In step S402, the mapping matrix is ​​queried to obtain the execution weight of each verification task in the current design stage.

[0065] Using the current design phase as an index, the mapping matrix is ​​queried, all verification tasks are traversed, and the execution weight corresponding to the current design phase column is extracted from the mapping matrix. By using the mapping matrix, the reliance on human experience is reduced, avoiding missed tests (missing high-weight tasks) or wasted resources (mistakenly selecting low-weight tasks) due to human error, and ensuring the consistency and standardization of the verification process across different projects.

[0066] In step S403, the verification tasks with execution weights greater than or equal to the enable threshold are identified as target verification tasks.

[0067] Based on a preset enabling threshold, such as 0.5, the execution weight of each queried verification task is compared with this threshold. If the execution weight of a verification task is greater than or equal to the enabling threshold, then the verification task is determined to be the target verification task. If the execution weight of a verification task is less than the enabling threshold, then the verification task is determined to be unnecessary to execute in the current design phase.

[0068] The enable threshold is a dynamically changing value. Specifically, maturity levels for different design stages are predetermined. As integrated circuit projects progress from RTL0 to TO maturity levels, the maturity increases. In the early stages (low maturity), the design is not only unstable but also has many defects. At this time, a strategy of rapid iteration and focusing on major defects should be adopted. Therefore, a higher enable threshold can be set, such as 0.7, allowing only the most critical and highest priority verification tasks to pass the screening, in order to quickly expose major problems. In the later stages (high maturity), in order to ensure zero defects in the tape-out, full-coverage regression testing must be performed. Therefore, the enable threshold needs to be lowered, such as 0.1, so that the vast majority of verification tasks can be executed after screening.

[0069] It can also monitor the resource load status of the computing cluster 300 in real time, such as CPU utilization and the number of queued jobs. When computing resources are scarce, i.e., the load is high, the enable threshold is dynamically increased to suppress the submission of low-priority verification tasks, prevent system overload, and ensure that high-priority verification tasks can obtain sufficient computing power. When computing resources are idle (low load), the enable threshold is decreased to allow more minor verification tasks to run, making full use of idle resources for more extensive testing.

[0070] The dynamic enable threshold adjustment mechanism enables the process control to be adaptive. The maturity-based adjustment conforms to the objective laws of chip R&D and effectively balances progress and quality. The resource load-based adjustment achieves the optimal allocation of computing resources, avoids blocking caused by resource contention, and ensures the priority execution of key verification tasks.

[0071] After identifying the target verification task and marking it as enabled, the system enters the execution phase. In some embodiments, such as... Figure 5 The diagram shows the process flow of the target verification task during the execution phase, including the following steps S501 to S503.

[0072] In step S501, in response to the trigger command for the target verification task, control commands adapted to the EDA tool are generated according to preset configuration parameters.

[0073] The trigger command can be manually initiated by the user by clicking the "run" button in the "Task Plan" view of the visual interface, or it can be automatically initiated by the upper-level scheduler after the prerequisite conditions are met (such as the previous verification task passing). In response to the trigger command, the configuration state of the target verification task is first locked to prevent the parameters from being accidentally modified during execution.

[0074] The system has a built-in script template library that stores standard script frameworks for different EDA tools and verification steps. The script templates reserve variable placeholders defined by special tags. Based on the type identifier of the target verification task, the corresponding script template is indexed and loaded from the library.

[0075] The preset configuration parameters include project-level design environment parameters and task-level task configuration parameters. Design environment parameters refer to the global settings for the current integrated circuit project, such as process node, standard cell library path, memory macrocell library path, clock cycle constraints, etc. These parameters typically apply to all verification tasks in the project. Task configuration parameters are personalized settings for the specific target verification task. Users can configure the number of scan chains, compression ratio, coverage target, etc.

[0076] Control instructions refer to the sequence of commands or script files that EDA tools can recognize and execute. The system uses the read design environment parameters and task configuration parameters to instantiate and populate the variable placeholders in the script template.

[0077] For example, if a script template contains the command `set_scan_configuration -chain_count {CHAIN_CNT}`, and the task configuration parameter `CHAIN_CNT` is set to 16, then this line would be replaced with `set_scan_configuration -chain_count 16`. This generates an executable script file adapted to the current design phase. In addition, the system also constructs command-line statements to launch the EDA tools. These statements include not only the EDA tool's startup command but also specify the input script path, output log path, etc. Control instructions include script files and command-line statements.

[0078] The standardized design of script templates ensures the consistency and compatibility of generated script files, avoiding syntax errors and logical confusion caused by manual script writing; the automatic acquisition and filling of environment parameters and task configuration parameters realizes the automatic generation of script files, greatly reducing manual operations by users and improving the efficiency of task execution; the automatic generation of command line statements simplifies the calling process of EDA tools, eliminating the need for users to manually enter complex command line commands.

[0079] In step S502, the EDA tool is invoked to execute control commands, and the log files output by the EDA tool during execution are monitored.

[0080] The system starts the EDA tool process through an operating system-level interface (such as Linux shell commands or system calls) and passes the generated control instructions to the process. During the execution of the EDA tool, detailed information, warnings, and errors are written to a designated log file in real time, and changes to the log file are continuously monitored.

[0081] In step S503, the feature information in the log file is parsed, and the execution status of the target verification task is updated in real time based on the parsing results.

[0082] Feature information refers to key strings or patterns with specific semantics in the log text, such as "Successfully completed" for success, "Error:" or "Fatal:" for failure, or stage markers representing specific progress. Parsing can be performed using regular expressions or string matching algorithms to scan and extract information from the log content read in real time.

[0083] Multiple verification tasks can be displayed in a matrix form in the visual interface; according to the execution weight and execution status, each cell in the matrix is ​​rendered with different colors or graphics, where different colors correspond to the statuses of disabled, selected, script generated, running, passed, and failed, respectively.

[0084] Based on the parsed feature information, the execution status of the target verification task is updated. Specifically, after the target verification task is submitted, the system starts a status monitoring daemon to monitor the execution process of the EDA tool in real time, and to analyze the file behavior and log content in the working directory in real time.

[0085] The monitoring process polls the working directory of the task, and when a script file with a specific suffix (such as...) is detected... When the .tcl file is successfully created and its size is greater than 0, the script is considered to have been successfully generated. The execution status is "script generation status". The corresponding cell in the GUI interface can be rendered in light yellow to indicate to the user that the script is ready.

[0086] When the last modification time of the log file output by the monitoring EDA tool is constantly being updated, or the file size is continuously increasing, it indicates that the EDA tool is actively writing data. The execution status is determined to be running, and the cell can be rendered as dark yellow or a dynamic rotating icon can be displayed to indicate that the target verification task is being executed.

[0087] Using a pre-defined regular expression engine, the system scans for new content in the log file line by line. Based on an error keyword library, including characteristic strings such as "Error:", "Fatal:", "Violations found", and "Design rule error", if any of these error keywords is matched in the log file, the task is considered to have failed, the execution status is marked as failed, and the cell can be rendered in red.

[0088] When the EDA tool process exits with an exit code of 0, if there are no error keywords in the log file and / or a success keyword such as "Successfully completed" or "End of session" is matched at the end of the log, the task is considered successful, the execution status is successful, and the cell can be rendered in green.

[0089] For example, such as Figure 6 The image shows a visual representation of the verification task. Different fill colors represent different values ​​for the cells corresponding to the verification task. Dotted fill indicates dark gray, meaning the verification task is disabled and cannot be selected by the user; white fill indicates blue, meaning the verification task is enabled and can be selected by the user; vertical fill indicates red, meaning the verification task failed; horizontal fill indicates green, meaning the verification task succeeded; diagonal fill indicates light yellow, meaning the script file for the verification task has been generated; and grid fill indicates dark yellow, meaning the verification task is currently being executed.

[0090] Based on the status judgment logic of log file feature information, the system realizes automated and real-time monitoring of the execution status of verification tasks, eliminating the need for users to manually check log files and significantly reducing operational complexity. The classification and definition of error keywords and success keywords improve the accuracy and pertinence of status judgment, enabling rapid identification of different types of task execution results. The extraction and display of error prompts provide effective support for users to quickly locate problems and improve debugging efficiency. Color-coded indicators for different statuses allow users to intuitively and quickly identify the task execution status, enhancing the user experience.

[0091] In this embodiment, scripts are generated based on templates and parameters, eliminating the risk of syntax errors (such as spelling mistakes and missing paths) caused by manually writing scripts, ensuring the consistency and standardization of all target verification tasks. Furthermore, by monitoring log characteristics in real time, the originally black-box EDA execution process becomes transparent and visible. In large-scale integrated circuit designs, there may be hundreds of concurrent verification tasks, and it is impossible for humans to monitor every execution window in real time. The state machine mechanism in this embodiment can automatically capture anomalies and provide intuitive feedback through color, allowing engineers to intuitively grasp the project's health status, greatly reducing monitoring costs and shortening the cycle from problem discovery to resolution.

[0092] In actual chip design flows, the vast majority of verification tasks run in batch mode by default. This mode is characterized by tools running in the background and only outputting log files. However, when a task fails, relying solely on static log files is often insufficient to pinpoint deep-seated logic errors or timing violations. Therefore, this embodiment provides a control mechanism that allows switching from batch mode to interactive debug mode.

[0093] In such Figure 7 The task configuration interface shown displays various information about the verification task, design module, and execution steps. When the status of a target verification task turns red (failure), a debug request can be initiated through the user interface. The specific steps include: in the task properties panel, finding the execution mode option and changing it from the default batch mode to interactive debug mode. The grid filling in the image indicates that "Interactive" is selected and switched to. Click the "run" or "debug" button (the "debug" button is not shown in the image). After receiving this trigger command, the system will suspend the original batch scheduling logic and instead invoke the interactive execution engine.

[0094] In interactive debugging mode, the target verification task is no longer submitted to the remote computing cluster queue 300. Instead, the EDA tool process is typically launched on the local server or a reserved debugging server first. The system calls the operating system's underlying window management interface (such as X11 forwarding or VNC session) to pop up a visual interactive terminal window for the EDA tool process. In the interactive terminal window, the system automatically loads the design environment, including setting the license path, library file path, and loading the script file corresponding to the target verification task. At this point, the user has complete control over the EDA tool and can directly enter design commands in the interactive terminal window or call waveform viewing tools to visually observe the transitions of circuit signals. This debugging environment greatly lowers the barrier for engineers to manually set up a debugging environment.

[0095] Different EDA task types have completely different operating mechanisms and data structures. To maximize debugging efficiency, this embodiment designs specific environment recovery and hold logic for two typical tasks: circuit insertion and formal verification.

[0096] For circuit insertion type target verification tasks, such as DFT circuit insertion or logic synthesis, the core output is a netlist in memory. In batch mode, the last line of the script is usually an `exit` or `quit` instruction, causing the tool to exit immediately after running or reporting an error, releasing the netlist in memory. If an engineer wants to view the connection relationships of a specific register, the script must be rerun, which can take hours for large SoC designs. In interactive debug mode, the system dynamically corrects the script when generating control instructions. Specifically, the system automatically identifies and comments out exit instructions at the end of the script, or adds specific keep-alive parameters when starting the EDA tool. After the script file finishes executing in the interactive terminal window, the tool's shell prompt remains on the screen, and the process is active. At this point, the complete netlist data has been loaded into memory. Engineers can directly enter various query commands to instantly query circuit structure and timing information, and re-execute the script file without waiting for the lengthy reloading and netlist generation process.

[0097] For formal verification tasks, the execution process typically involves lengthy mathematical proofs. If a task fails after 10 hours, requiring engineers to rerun it to reproduce the failure is highly inadvisable. Most formal verification tools support checkpointing or session saving, generating session snapshot files with the .fss extension (or other specific formats). When starting such a task in interactive debug mode, the system first scans the task's working directory to check for historical verification session files. If a historical verification session file is detected, selecting the "XXX.fss" historical verification session file shown in the image and clicking "Show" will open it, instead of executing the verification script from scratch. This allows EDA tools to restore the environment to the moment before the task failure within seconds, enabling users to immediately open the GUI to analyze counterexamples or pending assertions.

[0098] In this embodiment, for circuit insertion type target verification tasks, process keep-alive is used to avoid repeated loading and releasing of netlist data, thereby reducing the response time of debugging queries. For formal verification type target verification tasks, session file loading reuses historical calculation results, avoiding repeated calculations of known logic proof processes, greatly saving expensive EDA computing power. This interactive debugging mode significantly improves the iteration speed of chip verification, thereby shortening the chip development cycle.

[0099] Furthermore, this embodiment of the disclosure also supports users in creating a custom regression list containing multiple target verification tasks based on current verification requirements. Specifically, it receives the user-defined regression list containing multiple target verification tasks; for each target verification task in the regression list, it executes script generation and EDA tool calls concurrently or sequentially. Finally, it aggregates the execution status of all tasks in the regression list and counts the number of tasks in each status.

[0100] The regression list is mapped to a sequence of task objects. Each task object contains the task's configuration parameters, script template path, working directory path, and preset weight values. Users can perform user-defined regression list deletion operations on the generated regression list, or add or delete target validation tasks in the regression list.

[0101] like Figure 8 The image shows a schematic diagram illustrating the overall health of the regression lists in the aggregated view. Regression List 1 and Regression List 2 are used as examples. The interface displays the following statistical indicators in real time: Total, the total number of tasks in the list; Pending, the number of tasks waiting to be executed; Running, the number of tasks currently being executed; Finished, the number of completed tasks; Passed, the number of tasks that passed verification; Failed, the number of tasks that failed verification; Unknown, the number of tasks with an unknown status.

[0102] When a user selects one or more regression lists in the regression test management interface and clicks the "run" button, the system's internal scheduling engine immediately starts, and clicking the "GenScript" button generates script files in batches. The system allows users to configure execution strategies for each regression list, such as concurrent execution mode, suitable for independent target verification tasks with no data dependencies, or sequential execution mode, suitable for task chains with logical dependencies. The generated script files and log files can also be displayed in an aggregated view, such as... Figure 8 As shown below.

[0103] To improve debugging efficiency, the statistics themselves are also interactive controls. For example, when the number of failed tasks is not zero, the user can double-click the number, and the system will automatically jump to the debugging page, automatically filter out all failed tasks, and display their script paths and log paths for engineers to directly troubleshoot.

[0104] Figure 9 This disclosure presents a structural block diagram of a flow control device for integrated circuit design, such as... Figure 9As shown, it includes: a determination part 901 and a filtering and marking part 902; the determination part 901 is configured to determine the execution weight of multiple verification tasks in the current design stage according to preset association rules; the filtering and marking part 902 is configured to filter out the target verification task from multiple verification tasks based on the execution weight, and mark the target verification task as enabled.

[0105] In some embodiments, the association rule is a mapping matrix, which includes the execution weights of each verification task at different design stages; the filtering and labeling section 902 is configured to query the mapping matrix to obtain the execution weights of each verification task at the current design stage; and to identify the verification tasks whose execution weights are greater than or equal to the enable threshold as target verification tasks.

[0106] In some embodiments, the process control apparatus for the integrated circuit design further includes: an extraction section and a correction section; the extraction section is configured to extract the historical failure rate and defect detection efficiency of each verification task at the same design stage from historical projects with a similarity higher than a similarity threshold to the current integrated circuit project; the determination section 901 is configured to determine the change rate of the code of the verification task and the corresponding previous version code; the correction section is configured to correct the execution weight of each verification task based on the historical failure rate, defect detection efficiency and change rate.

[0107] In some embodiments, the determining portion 901 is configured to determine the enable threshold for the current design phase based on the maturity level of the current design phase and / or the load status of the current computing resources.

[0108] In some embodiments, the process control device for the integrated circuit design further includes: a generation section, an execution and monitoring section, and a parsing and updating section; the generation section is configured to generate control instructions adapted to the electronic design automation (EDA) tool according to preset configuration parameters in response to a trigger instruction for the target verification task; the execution and monitoring section is configured to call the EDA tool to execute the control instructions and monitor the log files output by the EDA tool during execution; the parsing and updating section is configured to parse the feature information in the log files and update the execution status of the target verification task in real time according to the parsing results.

[0109] In some embodiments, the generation section is configured to: obtain the script template corresponding to the target verification task; read the design environment parameters of the current integrated circuit project and the configuration parameters of the target verification task; fill the script template with the design environment parameters and configuration parameters to generate a script file and command line statements to start the EDA tool.

[0110] In some embodiments, the parsing and updating section is configured to determine the execution status as script generation status when a corresponding script file exists in the working directory of the EDA tool; determine the execution status as running status when a log file is detected to be being updated; determine the execution status as failure status when an error keyword is matched in the log file; and determine the execution status as pass status when an error keyword is not matched and / or a success keyword is matched in the log file.

[0111] In some embodiments, the process control device for the integrated circuit design further includes: a modification section configured to change the execution mode to an interactive debugging mode and open an interactive terminal window based on a received debugging instruction for a target verification task, so as to allow the user to input debugging commands to the EDA tool or call a waveform viewing tool.

[0112] In some embodiments, the process control device for the integrated circuit design further includes: an execution and holding section and a loading section; the execution and holding section is configured to, in interactive debugging mode, if the target verification task is of the circuit insertion type, execute the script in the interactive terminal window and keep the tool from exiting after execution; the loading section is configured to, if the target verification task is of the formal verification type and a historical verification session file exists in the corresponding working directory, load the session file for debugging.

[0113] In some embodiments, the process control device for the integrated circuit design further includes: a display section and a rendering section; the display section is configured to display multiple verification tasks in a matrix form in a visualization interface; the rendering section is configured to identify each cell in the rendering matrix with different colors or graphics according to the execution weight and execution status, wherein the different colors correspond to the disabled, selected, script generated, running, passed and failed statuses, respectively.

[0114] In this embodiment, each part can implement the integrated circuit design process control method provided in the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0115] Please refer to Figure 10This illustration shows a schematic diagram of the hardware structure of an electronic device provided in an exemplary embodiment of this disclosure. In some examples, the electronic device may be at least one of devices such as a smartphone, smartwatch, desktop computer, laptop, virtual reality terminal, augmented reality terminal, wireless terminal, and laptop computer. The electronic device has communication functions and can access wired or wireless networks. The term "electronic device" can refer to one of multiple terminals; those skilled in the art will understand that the number of such terminals may be more or less. It is understood that the electronic device undertakes the computation and processing work of the technical solution of this disclosure, and this disclosure does not limit this aspect.

[0116] like Figure 10 As shown, the electronic device in this disclosure may include one or more of the following components: processor 1010 and memory 1020.

[0117] Optionally, the processor 1010 connects various parts within the electronic device using various interfaces and lines. It executes various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 1020, and by calling data stored in the memory 1020. Optionally, the processor 1010 can be implemented using at least one hardware form of Digital Signal Processing (DSP), Field Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 1010 can integrate one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), Neural-network Processing Unit (NPU), and baseband chip. Specifically, the CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content displayed on the touchscreen; the NPU implements Artificial Intelligence (AI) functions; and the baseband chip handles wireless communication. It is understandable that the aforementioned baseband chip may not be integrated into the processor 1010, but may be implemented using a separate chip.

[0118] The memory 1020 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 1020 may include a non-transitory computer-readable storage medium. The memory 1020 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 1020 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data created based on the use of the electronic device, etc.

[0119] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include a display screen, camera assembly, microphone, speaker, radio frequency circuit, input unit, sensors (such as accelerometer, angular velocity sensor, light sensor, etc.), audio circuit, WiFi module, power supply, Bluetooth module, etc., which will not be described in detail here.

[0120] This disclosure also provides a computer-readable storage medium storing at least one instruction that is executed by a processor to implement the flow control method for integrated circuit design as described in the various embodiments above.

[0121] This disclosure also provides a computer program product including computer instructions stored in a computer-readable storage medium; a processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the flow control method for implementing the integrated circuit design described in the above embodiments.

[0122] This disclosure also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described integrated circuit design flow control method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0123] It should be understood that the chip mentioned in the embodiments of this disclosure may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0124] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, servers, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

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

[0126] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0127] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0128] Those skilled in the art will recognize that the functions described in this disclosure in one or more of the examples above can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0129] It should be noted that the technical solutions described in this disclosure can be combined arbitrarily as long as they do not conflict.

[0130] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A flow control method for integrated circuit design, characterized by, The flow control method of the integrated circuit design comprises: According to a preset association rule, determine the execution weight of a plurality of verification tasks in a current design stage; Based on the execution weight, filter out a target verification task from the plurality of verification tasks, and mark the target verification task as an enabled state; The association rule is a mapping matrix, and the mapping matrix comprises the execution weight of each verification task in different design stages; The filtering out of the target verification task from the plurality of verification tasks based on the execution weight comprises: Query the mapping matrix to obtain the execution weight of each verification task in the current design stage; Determine the verification task with an execution weight greater than or equal to an enabled threshold as the target verification task.

2. The flow control method of integrated circuit design according to claim 1, wherein, The flow control method of the integrated circuit design further comprises: Extract the historical failure rate and defect detection efficiency of each verification task in the same design stage from historical projects similar to the current integrated circuit project and having a similarity higher than a similarity threshold; Determine the change rate of the code of the verification task and the corresponding previous version code; Based on the historical failure rate, defect detection efficiency and change rate, correct the execution weight of each verification task.

3. The flow control method of integrated circuit design according to claim 2, wherein, The flow control method of the integrated circuit design further comprises: Determine the enabled threshold of the current design stage based on the maturity level of the current design stage and / or the load state of the current computing resource.

4. The flow control method of integrated circuit design according to any one of claims 1 to 3, wherein, The flow control method of the integrated circuit design further comprises: In response to a trigger instruction for the target verification task, generate a control instruction adapted to an electronic design automation (EDA) tool according to a preset configuration parameter; Call the EDA tool to execute the control instruction, and monitor the log file output by the EDA tool during execution; Parse the feature information in the log file, and update the execution state of the target verification task in real time according to the parsing result.

5. The method of flow control of an integrated circuit design according to claim 4, wherein, The generation of the control instruction adapted to the EDA tool according to the preset configuration parameter in response to the trigger instruction for the target verification task comprises: Obtain the script template corresponding to the target verification task; Read the design environment parameters of the current integrated circuit project and the configuration parameters of the target verification task; Fill the script template with the design environment parameters and the configuration parameters to generate a script file and a command line statement for starting the EDA tool.

6. The method of flow control for integrated circuit design of claim 4, wherein, The parsing of the feature information in the log file and the updating of the execution state of the target verification task according to the parsing result comprises: In the case that the corresponding script file exists in the working directory of the EDA tool, determine that the execution state is a script generation state; In the case that it is detected that the log file is being updated, determine that the execution state is a running state; In the case that an error keyword is matched in the log file, determine that the execution state is a failure state; In the case that the error keyword is not matched in the log file and / or a success keyword is matched, determine that the execution state is a pass state.

7. The method of flow control for integrated circuit design of claim 4, wherein, The flow control method of the integrated circuit design further comprises: Based on the received debugging instruction for the target verification task, the execution mode is changed to an interactive debugging mode and an interactive terminal window is opened to allow a user to input a debugging command to the EDA tool or invoke a waveform viewing tool.

8. The flow control method of integrated circuit design according to claim 7, wherein, The flow control method of the integrated circuit design further includes: In the interactive debugging mode, if the target verification task belongs to a circuit insertion type, a script is executed in the interactive terminal window and the tool is kept from exiting after the execution is completed; If the target verification task belongs to a formal verification type and a historical verification session file exists under a corresponding working directory, the session file is loaded for debugging.

9. The flow control method of integrated circuit design of claim 1, wherein, The flow control method of the integrated circuit design further includes: In the visual interface, a plurality of verification tasks are displayed in a matrix form; According to the execution weight and the execution state, each cell in the matrix is rendered with different colors or graphics, where different colors correspond to different states of unenabled, selected, script generated, running, passed and failed.

10. A flow control apparatus for integrated circuit design, characterized by The flow control device of the integrated circuit design includes a determination part and a screening and marking part. The determination part is configured to determine execution weights of a plurality of verification tasks at a current design stage according to a preset correlation rule. The screening and marking part is configured to screen a target verification task from the plurality of verification tasks based on the execution weights and mark the target verification task as an enabled state. The correlation rule is a mapping matrix including corresponding execution weights of each verification task at different design stages. The screening and marking part is specifically configured to query the mapping matrix to obtain the corresponding execution weights of each verification task at the current design stage; and determine a verification task with an execution weight greater than or equal to an enabled threshold as the target verification task.

11. An electronic device, comprising: The processor, the memory and the program or instructions stored on the memory and executable on the processor are included, and the program or instructions are executed by the processor to implement the steps of the flow control method of the integrated circuit design according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The program or instructions are stored on the computer readable storage medium, and the program or instructions are executed by the processor to implement the steps of the flow control method of the integrated circuit design according to any one of claims 1 to 9.

Images