DFT process monitoring methods, devices, electronic equipment, and storage media

Abstract

This disclosure provides a method, apparatus, electronic device, and storage medium for monitoring the execution of Design Automation (EDA) tasks, belonging to the field of DFT technology. The DFT process monitoring method includes: in response to the detected completion of the current test task, acquiring the process status and the current log file generated during the execution of the current test task; determining the target predefined parsing rule corresponding to the type of EDA tool used to execute the current test task through a mapping relationship between EDA tool types and predefined parsing rules; parsing semantic keywords from the current log file using the target predefined parsing rule; and determining the final execution status of the current test task based on the process status and semantic keywords. This solution can parse massive amounts of unstructured log files generated by different EDA tools and determine the final execution status of each test task.

Description

Technical Field

[0001] This disclosure relates to the field of Design for Test (DFT) technology, and more particularly to a DFT process monitoring method, apparatus, electronic device, and storage medium. Background Technology

[0002] As semiconductor manufacturing processes evolve towards advanced nodes such as 7nm, 5nm, and even 3nm, the design complexity of very large-scale integrated circuits (VLSI) is increasing exponentially. Design for Surface Steps (DFT), as a crucial step in ensuring chip manufacturing yield and quality, has become an indispensable part of the chip design flow. A typical DFT project usually involves several extremely complex engineering stages, including ScanInsertion, Memory Built-In Self-Test (MBIST), Automatic Test Pattern Generation (ATPG), Formal Verification, DFT simulation verification, and timing analysis.

[0003] In practical engineering, to handle the scale of hundreds of millions of transistors, the DFT process is usually broken down into hundreds or thousands of independent test tasks. These test tasks are executed by different EDA tools, and the execution process generates massive amounts of unstructured log files. These log files are scattered and stored in deeply nested file system directories, and the log file formats output by different EDA tools are also different.

[0004] In related technologies, project managers and DFT engineers primarily rely on a passive, manual approach to monitor project status. Engineers often need to manually delve into each directory to review log files, relying on personal experience to identify key information and determine the success of test tasks. Overall project progress statistics typically depend on periodic manual reporting.

[0005] This method of manually viewing logs is inefficient and error-prone. Manually parsing thousands of lines of logs is not only extremely time-consuming, but also prone to causing the omission of critical error information due to fatigue. Summary of the Invention

[0006] This disclosure provides a method, apparatus, electronic device, and storage medium for monitoring DFT processes, which can parse massive amounts of unstructured log files generated by different EDA tools and determine the final execution status of each test task.

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

[0008] Firstly, this disclosure provides a process monitoring method for Design of Functions (DFT). This method includes: in response to the detected completion of the current test task, obtaining the process status and the current log file generated during the execution of the current test task; determining the target predefined parsing rule corresponding to the type of EDA tool used to execute the current test task through the mapping relationship between EDA tool types and predefined parsing rules; parsing semantic keywords from the current log file using the target predefined parsing rule; and determining the final execution status of the current test task based on the process status and semantic keywords. This process requires no manual intervention; the final execution status of each test task is output immediately after completion, and this final execution status integrates the process status and semantic keywords from the log file, ensuring the accuracy of the final execution status determination. This process efficiently and accurately outputs the final execution status of each test task, avoiding the tedious operation of manually retrieving log files by the user.

[0009] In some embodiments, the DFT process monitoring method includes: determining the health index of the corresponding test step based on the final execution status of all test tasks included in each test step.

[0010] In some embodiments, health metrics include the current pass rate and the overall pass rate; the current pass rate is the ratio of the number of test tasks that have passed to the total number of test tasks executed; the overall pass rate is the ratio of the number of test tasks that have passed to the total number of test tasks planned to be executed. These two metrics can intuitively reflect the quality and progress of a testing process.

[0011] In some embodiments, the DFT process monitoring method includes: obtaining the current turning point threshold corresponding to the current milestone; determining the color value corresponding to the health indicator based on the current turning point threshold using a nonlinear color mapping algorithm; and rendering and displaying the icon representing the health indicator on the graphical user interface (GUI) according to the color value. Converting the health indicator from numerical values ​​to a color representation that is more sensitive to the human eye further enhances the intuitiveness for users.

[0012] In some embodiments, based on the current turning point threshold, a nonlinear color mapping algorithm is used to determine the color value corresponding to the health indicator. This includes: when the health indicator is less than or equal to the current turning point threshold, the generated color value gradually changes within a first color interval, and the rate of change of the color value is proportional to the ratio of the health indicator to the current turning point threshold; when the health indicator is greater than the current turning point threshold, the generated color value gradually changes within a second color interval, and the rate of change of the color value is proportional to the ratio of the complement of the health indicator to the complement of the current turning point threshold. The turning point threshold changes with milestones, giving the monitoring system time-dimensional adaptability. In the early stages of a project, it avoids alarm fatigue caused by a large number of failures triggering widespread red alerts. In the later stages of a project, it rigorously controls and visually amplifies minor risks, forcing users to focus on a small number of failed test tasks in the later stages of the project.

[0013] In some embodiments, the final execution status of the current test task is determined based on process status and semantic keywords, including: if the process status indicates that it is running, the final execution status is determined to be unknown; if the process status indicates that it terminated abnormally, the final execution status is determined to be failed; if the process status indicates that it ended normally and the semantic keywords include a predefined semantic pattern representing a logical error, the final execution status is determined to be failed; if the process status indicates that it ended normally and the semantic keywords do not include a predefined semantic pattern representing a logical error, the final execution status is determined to be passed. Since the process status usually only contains a few lines of code, in this embodiment, the process status is first used to determine whether the process was normally terminated by the EDA tool. If it was abnormally terminated by the operating system, it indicates that there must be a problem in the execution process of the test task, and the test task is directly determined to have failed, saving the computing power and time of parsing the log file. If the process ended normally, the semantic keywords in the log file are used to further determine whether the execution process of the test task was successful or effective, thereby obtaining the final execution status of the test task, ensuring that the determination of the final execution status is accurate and effective.

[0014] In some embodiments, the DFT process monitoring method further includes: obtaining context features that caused the failure from log files corresponding to test tasks whose final execution status is failed; determining the similarity between the context features of the failed test tasks; and outputting aggregated information based on the context features of multiple failed test tasks with a similarity greater than a similarity threshold, wherein the aggregated information is used to indicate that the failure reasons of multiple failed test tasks are the same. This disclosure reduces the number of log files requiring manual analysis from the number of test tasks to the number of failure categories. In a typical DFT regression test, the number of test tasks may be in the thousands, while the number of failure categories is usually only in the single digits. This allows engineers to locate common problems with a single click, compressing hours of troubleshooting work into minutes.

[0015] In some embodiments, the predefined parsing rules are regular expressions, and different EDA tool types correspond to different feature character sets. Specifically, the feature character set corresponding to the memory-built-in self-test tool includes characters representing memory repair failures; the feature character set corresponding to the formal verification tool includes characters representing proof failures; and the feature character set corresponding to the timing simulation tool includes characters representing waveform mismatches. Using regular expressions allows for easy addition and modification as needed, and provides high efficiency in extracting semantic keywords.

[0016] In some embodiments, the DFT process monitoring method further includes: generating a time-series stacked bar chart in the GUI according to the color associated with the final execution status of each test task, wherein the horizontal axis of the time-series stacked bar chart represents the time period or milestone version, and the vertical axis represents the number of test tasks. This allows for intuitive monitoring of the convergence trend of project progress.

[0017] In some embodiments, the DFT process monitoring method further includes: responding to a received selection operation on a target scenario-based view template, filtering out a set of test tasks associated with the target scenario-based view template based on preset filtering rules; in a two-dimensional grid constructed with design modules as row indices and test steps as column indices, rendering the corresponding cell with a color associated with the final execution state of each test task in the test task set according to the final execution state of each test task in the test task set; generating a time-stacked bar chart in the GUI according to the color associated with the final execution state of each test task in the test task set, with the horizontal axis of the bar chart representing the time period or milestone version, and the vertical axis representing the number of test tasks in the test task set. For SoC projects containing thousands of test tasks, displaying all of them would lead to information overload. By filtering with scenario-based view templates, users can block irrelevant information with one click as needed (e.g., MBIST engineers only need to see MBIST-related data), thereby quickly focusing on the risk points of concern and improving the efficiency and targeting of human-computer interaction.

[0018] Secondly, this disclosure provides a process monitoring device for Design of Electronics (DFT), comprising: an acquisition section, a determination section, and a parsing section; the acquisition section is configured to acquire the process status and the current log file generated during the execution of the current test task in response to the detected completion of the current test task; the determination section is configured to determine the target predefined parsing rule corresponding to the type of EDA tool used to execute the current test task through a mapping relationship between EDA tool types and predefined parsing rules; the parsing section is configured to parse semantic keywords from the current log file through the target predefined parsing rule; the determination section is further configured to determine the final execution status of the current test task based on the process status and semantic keywords.

[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 DFT process monitoring method 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 DFT process monitoring method 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 DFT process monitoring method 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 DFT process monitoring method as described in the first aspect.

[0023] This disclosure provides a method, apparatus, electronic device, and storage medium for DFT process monitoring. The method monitors each test task, acquiring its log file and process status upon completion. Based on the predefined parsing rules corresponding to the type of EDA tool used to execute the current test task, it comprehensively determines the final execution status of the test task based on the parsed semantic keywords and process status. This process requires no manual intervention; the final execution status of each test task is output immediately after completion, and this final execution status integrates the process status and semantic keywords from the log file, ensuring accurate determination of the final execution status. This process efficiently and accurately outputs the final execution status of each test task, avoiding the tedious manual retrieval of log files by the user. Attached Figure Description

[0024] Figure 1 This is an application environment architecture diagram for a DFT process monitoring method provided in this disclosure.

[0025] Figure 2 This is a flowchart illustrating a process monitoring method for DFT provided in this disclosure.

[0026] Figure 3 This is a schematic diagram of a two-dimensional grid provided in this disclosure.

[0027] Figure 4This is a schematic diagram of a time-stacked columnar structure provided in this disclosure.

[0028] Figure 5 A flowchart illustrating another process monitoring method for DFT provided in this disclosure.

[0029] Figure 6 This is a schematic diagram illustrating how color values ​​change with health indicators, as provided in this disclosure.

[0030] Figure 7 This is a schematic diagram illustrating the current pass rate of a test procedure provided in this disclosure.

[0031] Figure 8 This is a flowchart illustrating another DFT process monitoring method provided in this disclosure.

[0032] Figure 9 This is a flowchart illustrating yet another DFT process monitoring method provided in this disclosure.

[0033] Figure 10 This is a structural block diagram of a process monitoring device for DFT provided in this disclosure.

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

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

[0036] First, refer to Figure 1 This diagram illustrates the application environment architecture of a DFT process monitoring method provided in this embodiment of the disclosure. Figure 1 As shown, it includes a computing cluster layer 110 and a terminal device 120. In this embodiment, the electronic device (i.e., the execution entity) can be a management node in the computing cluster 110, an independent monitoring server, or a terminal device in the user interaction layer.

[0037] Specifically, the computing cluster layer 110 typically consists of a high-performance server group with a job scheduling system deployed. In this disclosure, the computing cluster layer 110 also deploys a monitoring system capable of executing the DFT process monitoring method provided in this disclosure. In DFT engineering practice, engineers use the job scheduling system to deliver a large number of test tasks to computing nodes for parallel execution. Each test task corresponds to a specific EDA tool call, such as running an ATPG generation process or performing a Corner gate-level simulation. During execution, the EDA tool writes execution process information to a log file.

[0038] The computing cluster layer 110 includes a database for centralized storage of all project data, including RTL design code, netlists, scripts, and log files. The terminal device 120 includes a desktop computer, workstation, or laptop. The terminal device 120 runs a graphical user interface (GUI), which communicates with the computing cluster layer 110 via a network to present the information computed by the computing cluster layer 110 to the user.

[0039] In this embodiment, in order to map the discrete logs in the physical file system into logically manageable entities, the DFT project is constructed as a structured four-layer data model for easy management. The four-layer data model includes: Milestone: representing the time node version of the project (such as RTL0.5, RTL1.0, Netlist_Freeze, etc.), and each milestone corresponds to a complete set of verification targets.

[0040] Design Module: Represents a logical hierarchy unit within a chip (such as GPU_Top, DDR_Controller, CPU_Core, etc.). Test Step: Represents a specific DFT technique step executed on a particular design module. Common test steps include, but are not limited to: scan chain insertion, formal verification, ATPG, DFT simulation, timing analysis, etc. Test Task: The smallest execution unit in process management. A test step may contain one or more test tasks. For example, under the DFT simulation test step, dozens of specific simulation tasks may need to be run for different process corners and different test modes, with each simulation task corresponding to a test task.

[0041] like Figure 2 As shown, this disclosure provides a method for monitoring the DFT process. The following example, using an electronic device as the execution subject, illustrates the method for monitoring the DFT process provided by this disclosure. This method may include steps S201 to S204 as described below.

[0042] In step S201, in response to the detected completion of the current test task, the process status and the current log file generated during the execution of the current test task are obtained.

[0043] The current test task refers to the smallest execution unit that is uniquely determined by the design module and test steps in the DFT process under a specific milestone. The current test task is any test task that has been completed.

[0044] In the DFT workflow, test task execution is typically asynchronous and varies significantly in time (from minutes to days). To achieve real-time monitoring, the lifecycle status of test tasks can be obtained by periodically polling the job scheduling system or by subscribing to an event message queue indicating test task completion. When the monitoring system detects that the status of a test task has changed to "completed" or "exited," it determines that the corresponding current test task has ended.

[0045] Process state refers to the task completion code or signal returned by the operating system or job scheduling system, reflecting the final result of task execution. In specific implementations, process state can be identified by both the process's exit status and exit code. For example, normal exit is identified by the exit status "QProcess::NormalExit" and the exit code 0. Abnormal termination may be identified by the exit status "QProcess::CrashExit" (process crash) or by the exit status "QProcess::NormalExit" with a non-zero exit code (the program itself reported failure).

[0046] Test programs can specify the exact cause of failure by setting different non-zero exit codes, which can be used by the caller (such as a job scheduling system) for fine-grained error handling and information extraction. For example, exit code 1 indicates a runtime error; the program returns this code upon normal exit, meaning there is a problem with the business logic. Detailed error information is usually stored in standard output, which the caller can parse and extract. Exit code 2 indicates a command syntax error; the program also exits normally but returns this code. Its error description is usually directly located in standard error, which the caller can directly read and display.

[0047] Therefore, to determine whether a task is completely successful, its exit status (how it terminated) and exit code (why it terminated) can be checked simultaneously. This mechanism not only allows the system to determine the success or failure of a task, but also to obtain detailed diagnostic information when it fails and to implement different processing logic for different types of errors.

[0048] The monitoring system maintains a test task registry, recording the expected output path for each test task. When a completed test task is identified, the system retrieves the current log file from the log storage path of that test task, as found in the registry. To prevent incomplete data due to reading a log file that is currently being written, the monitoring system checks for file locks or waits until the file's last modification time has stabilized before retrieving it.

[0049] In step S202, the target predefined parsing rule corresponding to the type of EDA tool used to execute the current test task is determined by the mapping relationship between EDA tool type and predefined parsing rule.

[0050] Because the DFT process involves multiple tools from various vendors, the log formats output by different tools may differ. For example, Synopsys VCS (simulation tool) error messages typically include "Error between ..." format, while success messages include "No error between". Mentor Tessent (MBIST / ATPG tool) error messages may include " / / Error"; success messages may include "exit 0". Formality (formal verification tool) proof failure results are represented as "Verification FAILED", while success results are represented as "Verification SUCCEEDED".

[0051] To ensure compatibility with log files output by different EDA tools in various formats, this embodiment pre-defines an extensible rule base. This rule base stores a one-to-one mapping between EDA tool types and predefined parsing rules. Predefined parsing rules refer to pre-configured logical patterns used to extract structured information from unstructured text. First, the EDA tool used by the current test task is identified based on the test task's configuration attributes. Then, the target predefined parsing rule corresponding to that EDA tool type is retrieved from the rule base.

[0052] In step S203, semantic keywords are parsed from the current log file using predefined parsing rules for the target.

[0053] Semantic keywords are specific strings or contextual patterns existing within the text content of log files that reflect the execution logic of the tool. Examples include "Error," "Verification FAILED," and "Mismatch." Semantic keywords involve deep semantic analysis of the log file content; even if the process exits normally, serious logical errors may have occurred within the EDA tool. Therefore, it is necessary to parse the content of the log file.

[0054] In addition, the target predefined parsing rules will also scan the last preset line of the current log file to look for the exit information printed by the EDA tool, such as the regular expression r "Exit Status:\s+(\d+)", to reconfirm the process status and detect whether the process was closed normally by the EDA tool, rather than being forcibly terminated by the operating system due to abnormalities such as memory overflow.

[0055] To improve the efficiency of semantic keyword parsing, error and warning patterns can be prioritized. For example, in the TetraMAX tool, predefined parsing rules search for strings that match the beginning of a line error r "^Error:", a specific critical warning code r "M13", or an indication of no vector generation r "0 patterns generated". Predefined parsing rules may also extract specific numerical values, such as matching r "Test Coverage\s+:\s+([\d\.]+)%" to extract the coverage value. These extracted specific strings and values ​​are the semantic keywords.

[0056] In some feasible approaches, the predefined parsing rules are regular expressions, and different EDA tool types correspond to different feature character sets. The feature character set refers to the set of strings defined for a specific EDA tool that can uniquely represent the specific fault type of that EDA tool, such as the "Repair failed" character set for the MBIST tool.

[0057] The feature character set corresponding to the MBIST tool includes characters that characterize memory repair failures, such as the regular expression r"Error:. The message "Repairable memories found: 0" or " / / Error: Memory repairfailed" indicates a serious logical defect where the EDA tool failed to repair due to insufficient redundant resources, even though the tool had finished running. The feature character set corresponding to the formal verification tool includes characters representing proof failure, such as "\[Error\]Property". "is FALSIFIED" or "Verification failed" indicates that the design does not meet the mathematical constraints; the characteristic character set corresponding to the timing simulation tool includes characters that represent waveform mismatches, such as "Mismatch at time". Expect: Got: ", or r"UVM_ERROR". Using regular expressions, you can add or modify them as needed, and they are highly efficient at extracting semantic keywords.

[0058] In step S204, the final execution state of the current test task is determined based on the process state and semantic keywords.

[0059] The final execution status refers to the business-level conclusion of the test task determined by the monitoring system after comprehensive evaluation.

[0060] Simply relying on process exit codes is often inaccurate in the EDA field. Therefore, this embodiment uses combined and / or combinational logic for comprehensive determination. Specifically, the final execution status includes: Unstarted, Pass, Fail, and Unknown.

[0061] If the process status indicates that it is running, or the log file has not yet been generated, it is impossible to draw a conclusion, and the final execution status is determined to be unknown.

[0062] If the process status indicates abnormal termination, it means that the EDA tool has crashed or is short of resources. In this case, there is no need to search the log keywords; the final execution status can be directly determined as failure.

[0063] If the process status indicates normal termination, it cannot be directly considered successful. The extracted semantic keywords must be checked. If the semantic keywords include a predefined semantic pattern representing a logical error, it indicates that although the process completed, the result was incorrect, and the final execution status is determined to be failure. If the process status indicates normal termination, and the semantic keywords in the full log file parsing do not include a predefined semantic pattern representing a logical error, and an explicit success flag such as "Verification SUCCEEDED" may be matched, then the final execution status is determined to be successful. Predefined semantic patterns are specific text structures used to identify logical errors. They contain not only single keywords but also specific contextual combinations, such as "Error" being the keyword, and "Error:..." being the contextual pattern. "Design mismatch" is a semantic pattern.

[0064] If no process exists for the test task, the execution status of the test task is determined to be "not started".

[0065] Since process status typically involves only a few lines of code, this embodiment first determines whether the process was normally terminated by the EDA tool based on the process status. If it was abnormally terminated by the operating system, it indicates a problem in the test task execution process, and the test task is directly determined to have failed, saving computational power and time spent parsing log files. If the process terminated normally, the log file is further analyzed using semantic keywords to determine whether the test task execution process was successful or effective, thereby obtaining the final execution status of the test task and ensuring the accuracy and effectiveness of the final execution status determination.

[0066] To showcase the overall project, a two-dimensional grid view was created, such as... Figure 3 As shown, using design modules as row indices and test steps as column indices, the diagram illustrates design modules 1 to 6, test steps a and f. Each cell in the grid represents the execution status of a specific test step on a specific design module, i.e., the final execution state of a test task. The final cells are rendered and displayed based on the color associated with each final execution state, as shown below. Figure 3 As shown in the diagram, "pass" is represented by green (vertical fill), "failure" by red (diagonal fill), "unknown" by yellow (horizontal fill), and "not yet started" by gray (white fill). The GUI provides a more intuitive view of the final execution status of each test task.

[0067] In addition, to monitor the convergence trend of progress, this disclosure also provides a time-stacked histogram, where the horizontal axis of the time-stacked histogram represents the time period or milestone version, and the vertical axis represents the number of test tasks, such as... Figure 4 As shown, the horizontal axis represents milestone versions. For each time point, the height of the bar represents the total number of tasks. The interior of the bar is divided into different colored blocks, each representing the number of tasks in a different final execution state, filled with colors associated with the final execution state of each test task. Figure 4 As shown in the diagram, "pass" is represented by green (vertical fill), "failure" by red (diagonal fill), "unknown" by yellow (horizontal fill), and "not yet started" by gray (white fill).

[0068] In this embodiment, by monitoring each test task, the log file and process status of the test task are obtained after the test task is completed. Based on the predefined parsing rules corresponding to the type of EDA tool used to execute the current test task, the final execution status of the current test task is determined by comprehensively considering the parsed semantic keywords and process status. This process requires no manual intervention; the final execution status of each test task is output immediately after completion, and this final execution status integrates the process status and semantic keywords from the log file, ensuring the accuracy of the final execution status determination. This process efficiently and accurately outputs the final execution status of each test task, avoiding the tedious operation of manually retrieving log files by the user.

[0069] In order to indicate the quality and progress of test projects, in some embodiments, such as Figure 5 As shown, the process monitoring method for DFT includes the following steps S501 to S504.

[0070] In step S501, the health index of the corresponding test step is determined based on the final execution status of all test tasks included in each test step.

[0071] A test step refers to a logical step in the DFT process that has a specific technical objective, and includes a set of multiple specific test tasks. For example, MBIST circuit insertion is a step that may contain specific insertion test tasks for hundreds of different memory macros.

[0072] Health indicators are numerical parameters used to quantitatively evaluate the execution status of a test step at a specific point in time.

[0073] In some feasible implementations, health metrics include current pass rate and overall pass rate. Current pass rate refers to the pass rate calculated only for completed test tasks, while overall pass rate refers to the pass rate calculated for all planned test tasks.

[0074] Specifically, firstly, using the test step as the key, we retrieve records of all test tasks belonging to that test step from the database. Assuming there are N planned test tasks under a given test step, we iterate through the final execution states of these N tasks, classifying and counting them as follows: n1 of the tasks that passed; n2 of the tasks that failed; and n3 of the tasks with an unknown execution state. Then, the current pass rate R1 = n1 / (n1+n2), and the overall pass rate R2 = n1 / N.

[0075] The current pass rate reflects the current verification quality. For example, if only 10 test tasks have been run and all 10 have failed, the current pass rate is 0%. This can alert engineers to fundamental errors in the environment or scripts, allowing them to stop testing and make corrections without waiting for all test tasks to complete. The overall pass rate reflects the project's progress. For example, if N is 1000, and 10 tests have been run and all passed, although the current pass rate is 100%, indicating good quality, the overall pass rate is only 1%, indicating slow progress. These two metrics provide a direct reflection of the quality and progress of a testing process.

[0076] In step S502, the current turning point threshold corresponding to the current milestone is obtained.

[0077] The current inflection threshold is a critical value defined in project management (between 0 and 1, such as 0.3, 0.5, 0.8, etc.) used to distinguish between high-risk and safe convergence zones. This value is usually related to project milestones; for example, it is lower in the early stages of the project (high tolerance) and extremely high on the eve of tape-out (low tolerance).

[0078] Specifically, it reads the current milestone of the current project. For example, if it is currently in the "Alpha Release" stage, the transition threshold is set to 0.6 in the configuration file; if it is in the "Final Sign-off" stage, the transition threshold is increased to 0.95.

[0079] In other feasible ways, the turning point threshold can also be generated by a machine learning model based on the convergence curve of historical projects, or by the user adjusting it in real time on the GUI.

[0080] In step S503, based on the current turning point threshold, the color value corresponding to the health index is determined by a nonlinear color mapping algorithm.

[0081] Nonlinear color mapping algorithms refer to a calculation method that maps continuous numerical ranges to the Red Green Blue (RGB) color space. The slope of the mapping function changes abruptly at a specific threshold point, which can visually enhance the perception of key risk areas.

[0082] In some feasible implementations, each component of the RGB color space ranges from 0 to 255. The logic of the non-linear color mapping algorithm is as follows: the input is the health index R and the current turning point threshold T. The value of R is between 0 and 1, and it can be the current pass rate or the overall pass rate. Users can select the appropriate value on the GUI as needed.

[0083] The first color interval represents the warning zone, where R ≤ T. The visual target is a transition from pure red (255, 0, 0) to pure yellow (255, 255, 0). The red component (Red) remains saturated at 255, while the green component (Green) increases with the health index, i.e., Red = 255, Green = 255 × (R / T), and Blue = 0. At this point, the ratio of R to T represents the progress towards the passing grade; the smaller the ratio, the purer the red and the higher the warning level.

[0084] The second color interval represents the safe zone, R>T. The visual target transitions from pure yellow (255, 255, 0) to pure green (0, 255, 0). The green component remains saturated at 255, while the red component decays as the health index increases, i.e., Green=255, Red=255×(1-R) / (1-T), Blue=0. At this point, the complement (two numbers that sum to 1 are complements) is used for calculation. 1-R represents the distance from perfection. As R approaches 1, the red component quickly returns to zero, presenting pure green.

[0085] like Figure 6As shown, the horizontal axis represents the health index, with values ​​ranging from 0 to 1, and the vertical axis represents the RGB values, ranging from 0 to 255. The solid line represents the change in the Green component value; before the current threshold T, it increases linearly with the health index, and after T, it remains at 255. The dashed line represents the change in the Red component value; before the current threshold T, it remains at 255, and after T, it decreases linearly with the health index.

[0086] In step 504, icons representing health indicators are rendered and displayed on the GUI according to color values.

[0087] The front-end uses the Canvas API or the CSS background-color property to apply the calculated RGB values ​​to the circular or rectangular icons corresponding to the current test step. It can also overlay specific percentage values ​​(such as "85%)" in the center of the icon, allowing users to perceive both macro-level risk through color and precise numerical values.

[0088] like Figure 7 As shown, with the health index as the current pass rate, the current pass rate for test step a is 90%, and the icon with the lowest density fill is a pure green. The current pass rate for test step b is 70%, and the icon with the second lowest density fill is a light green. The current pass rate for test step c is 50%, and the icon with the second highest density fill is a light red. The current pass rate for test step d is 20%, and the icon with the highest density fill is a pure red.

[0089] In this embodiment of the disclosure, the turning point threshold changes with the milestone, which makes the monitoring system adaptive in the time dimension. In the early stage of the project, it does not report all failures as red and cause alarm fatigue. In the later stage of the project, it strictly controls the process, visually amplifies small risks, and forces users to pay attention to a small number of failed test tasks in the later stage of the project.

[0090] In some embodiments, such as Figure 8 As shown, the process monitoring method for DFT includes the following steps S801 to S807.

[0091] In step S801, in response to the detected completion of the current test task, the process status and the current log file generated during the execution of the current test task are obtained.

[0092] In step S802, the target predefined parsing rule corresponding to the type of EDA tool used to execute the current test task is determined by the mapping relationship between EDA tool type and predefined parsing rule.

[0093] In step S803, semantic keywords are parsed from the current log file using predefined parsing rules for the target.

[0094] In step S804, the final execution state of the current test task is determined based on the process state and semantic keywords.

[0095] In step S805, the context features that caused the failure are obtained from the log file corresponding to the test task whose final execution status is failure.

[0096] Contextual features refer to text segments extracted from log files that describe the environment in which the fault occurred. They typically contain key lines of error information and related lines before and after them, and remove dynamic noise such as timestamps and absolute paths.

[0097] Specifically, the process first locates the anchor point, iterates through all test tasks that have failed, opens the corresponding log file, and uses a pre-defined regular expression to search for error anchor points in the file. Once the anchor line i is located, the text content of the interval [iN, i+M] is automatically extracted.

[0098] For example, N (number of lines preceding the error) is set to 2, and M (number of lines following the error) is set to 5. This is because EDA tools typically print the error reason first, followed by the stack trace or status register value. The information following the error is crucial for distinguishing the fault type. The specific settings of N and M are determined according to the actual application needs, and this disclosure does not impose any limitations.

[0099] Clean the text content of lines [iN, i+M] to remove noise. For example, for timestamp cleaning, replace \d{2}:\d{2}:\d{2} or time=\d+ns with placeholders. <time>Path cleaning, replacing absolute paths containing / home / user / project / ... with... <path>Pointer or address cleaning, replacing the hexadecimal address 0x[0-9a-fA-F]+ with <addr>; Specific ID cleaning, uniformly replacing instance names in the form of u_cpu_core_0 to u_cpu_core_7 with<INSTANCE_ID> .

[0100] After cleaning, two seemingly different log entries, such as "Core 0 at 100ns timeout" and "Core 1 at 500ns timeout", will be transformed into the exact same feature string: "Core<INSTANCE_ID> at <time>timeout.

[0101] In step S806, the similarity between the contextual features of the failed test tasks is determined.

[0102] Similarity refers to the degree of closeness between two contextual features in terms of text structure or semantics, and is usually quantified as a value between 0 and 1 (or 0% to 100%).

[0103] Among the feasible methods, fingerprint comparison based on SimHash is suitable for determining similarity when the number of failed test cases is large, such as more than 10,000. Utilizing the SimHash technique in the Locality Sensitive Hash algorithm, the standardized context features are segmented, the hash value of each word is calculated, and the hash values ​​are weighted and merged to generate a 64-bit integer fingerprint. The Hamming distance between two fingerprints is calculated; if the Hamming distance is ≤3 (an empirical value, corresponding to approximately 95% similarity), the two are considered highly similar. This method is extremely fast, with a complexity of O(log n). O (N).

[0104] Among other feasible methods, Levenshtein edit distance is suitable for a small number of failed test cases with high accuracy requirements, such as fewer than 1000 records. It calculates the minimum number of single-character edits (insertion, deletion, replacement) required to transform one feature string into another. The determined similarity calculation formula is: Similarity = 1 - EditDistance / Max(Len1, Len2), where Len1 is the string length of the context feature S1 to be compared for similarity, Len2 is the string length of the other context feature S2 to be compared for similarity, EditDistance is the minimum number of single-character edits required to transform S1 into S2, and Similarity is the similarity score. The calculated Similarity is compared to see if it exceeds a preset similarity threshold (e.g., 0.95). This method has high accuracy and can identify subtle text differences, but it has a high computational cost.

[0105] In step S807, aggregated information is output based on the contextual features of multiple failed test tasks with similarity greater than a similarity threshold.

[0106] The similarity threshold is a numerical boundary used to determine whether two faults belong to the same category. This threshold can be set from 0.90 to 0.98, depending on the algorithm used.

[0107] Aggregated information is used to indicate that multiple failed test tasks have the same cause of failure. It can be a summary of multiple failed test tasks with high similarity, which usually includes a representative log fragment and the frequency of occurrence of this type of failure.

[0108] The monitoring system maintains a dynamic list of fault clusters. For each newly processed failed test task, its context features are compared with the representative features of existing clusters. If the similarity meets the threshold of a cluster, the task is assigned to that cluster, and the cluster's counter is updated. If no existing cluster is matched, a new fault cluster is created, and the current context features are set as the representative features of that cluster.

[0109] Without clustering, when environmental problems occur, users will see 5,000 red failure icons and have to click on them one by one to check if they are for the same reason, which wastes a lot of time.

[0110] On the GUI interface, if 5000 test tasks fail, instead of listing 5000 lines of errors, aggregated information is output, such as: "Quantity: 4850, 'Test Compilation' function license verification failed on server A", "Quantity: 120, scan chain 'chain_1' is in place". <num>"Blocked at pin", "Quantity: 30, Analog Mismatch: Expected Value 1, Actual Value 0, Located at pin"<PIN_NAME> ".

[0111] Furthermore, representative contextual features can be stored in a knowledge base. When a cluster of highly similar faults appears in the next project, historical solutions can be output, such as "It is recommended to check the clock constraint file," so that solutions can be directly obtained for typical test failure reasons.

[0112] This disclosure reduces the number of log files requiring manual analysis from the number of test tasks to the number of fault categories. In a typical DFT regression test, the number of test tasks may be in the thousands, while the number of fault categories is usually only in the single digits. This allows engineers to locate common problems with a single click, compressing hours of troubleshooting work into minutes.

[0113] DFT engineering involves numerous roles, each with different focuses. For example, front-end DFT engineers focus on the logical insertion of design modules, while back-end verification engineers focus on waveform comparison during simulation verification. To avoid information overload, embodiments of this disclosure provide a scene-based view template function. Figure 9 As shown, the process monitoring method for DFT includes the following steps S901 to S903.

[0114] In step S901, in response to the received selection operation of the target scene view template, a set of test tasks associated with the target scene view template is selected based on preset filtering rules.

[0115] Preset filtering rules refer to the logical conditions defined in the template, which can be regular expressions for test step names, tag matching for design modules, or Boolean logic combinations for task attributes.

[0116] A target scenario-based view template refers to a predefined set of filtering rules used to select a subset of data from the full testing task for a specific technical field or area of ​​interest. For example, the scenario-based view template corresponding to the ATPG focus mode only includes steps related to the generation of scan chain test vectors; the scenario-based view template corresponding to critical path simulation may only include timing simulation tasks involving the core CPU module.

[0117] Users can click the Scene View drop-down menu in the top navigation bar of the GUI interface and select a scene view template from the list. Scene view templates may include: DFT Design, DFT Simulation, Timing Analysis, ATPG, Coverage, Gate Simulation, and Test Pattern Generator (TPG). When this selection is captured, a unique identifier for the target scene view template is obtained.

[0118] The corresponding configuration object is loaded based on this unique identifier. This configuration object may contain rules such as those in JSON format, for example:

[0119] {

[0120] "filter_type": "regex_match",

[0121] "step_pattern": "^mbist_". / / Matches only test steps that begin with mbist_

[0122] "design_tag": "include_all"

[0123] }

[0124] Iterate through all test tasks under the current milestone, applying the above regular expression. Only test tasks whose test step names match "^mbist_" will be considered. Only when the condition is met will the test task be added to the test task set.

[0125] In step S902, in a two-dimensional grid constructed with design modules as row indices and test steps as column indices, the corresponding cell is rendered with a color associated with the final execution state, based on the final execution state of each test task in the test task set.

[0126] This step can be referenced from the above. Figure 3 Related descriptions, Figure 3 The table shows all the test tasks. This step shows only some of the test tasks under the target scenario view template, which will not be described in detail here.

[0127] In step S903, a time-stacked bar chart is generated in the GUI according to the color associated with the final execution status of each test task in the test task set.

[0128] This step can be referenced from the above. Figure 4 Related descriptions, Figure 4 The table shows all the test tasks. This step shows only some of the test tasks under the target scenario view template, which will not be described in detail here.

[0129] For SoC projects containing thousands of test tasks, displaying all of them would lead to information overload. By using scenario-based view templates for filtering, users can filter out irrelevant information with a single click (for example, MBIST engineers only need to see MBIST-related data), thereby quickly focusing on the risk points of concern and improving the efficiency and relevance of human-computer interaction.

[0130] Figure 10 This disclosure presents a structural block diagram of a DFT process monitoring device, as shown below. Figure 10 As shown, it includes: an acquisition section 1001, a determination section 1002, and a parsing section 1003; the acquisition section 1001 is configured to acquire the process status and the current log file generated during the execution of the current test task in response to the detected completion of the current test task; the determination section 1002 is configured to determine the target predefined parsing rule corresponding to the type of EDA tool used to execute the current test task through the mapping relationship between the EDA tool type and the predefined parsing rule; the parsing section 1003 is configured to parse semantic keywords from the current log file through the target predefined parsing rule; the determination section 1002 is also configured to determine the final execution status of the current test task based on the process status and semantic keywords.

[0131] In some embodiments, the determining portion 1002 is further configured to determine the health index of the corresponding test step based on the final execution status of all test tasks included under each test step.

[0132] In some embodiments, the health metrics include the current pass rate and the overall pass rate; the current pass rate is the ratio of the number of test tasks that have been successfully executed to the total number of test tasks executed; the overall pass rate is the ratio of the number of test tasks that have been successfully executed to the total number of test tasks planned to be executed.

[0133] In some embodiments, the DFT process monitoring device further includes: a display section; an acquisition section 1001, further configured to acquire the current turning point threshold corresponding to the current milestone; a determination section 1002, further configured to determine the color value corresponding to the health index based on the current turning point threshold using a nonlinear color mapping algorithm; and a display section, configured to render and display icons representing the health index on a graphical user interface (GUI) according to the color values.

[0134] In some embodiments, the determining portion 1002 is further configured to, when the health index is less than or equal to the current turning threshold, generate a color value that gradually changes within a first color range, with the rate of change of the color value being proportional to the ratio of the health index to the current turning threshold; and when the health index is greater than the current turning threshold, generate a color value that gradually changes within a second color range, with the rate of change of the color value being proportional to the ratio of the complement of the health index to the complement of the current turning threshold.

[0135] In some embodiments, the determining portion 1002 is further configured to determine the final execution state as unknown if the process state indicates that it is running; determine the final execution state as failed if the process state indicates that it terminates abnormally; determine the final execution state as failed if the process state indicates that it ends normally and the semantic keyword includes a predefined semantic pattern representing a logical error; and determine the final execution state as passed if the process state indicates that it ends normally and the semantic keyword does not include a predefined semantic pattern representing a logical error.

[0136] In some embodiments, the DFT process monitoring device further includes an output section; an acquisition section 1001, further configured to acquire context features that caused the failure from a log file corresponding to a test task whose final execution status is failure; a determination section 1002, further configured to determine the similarity between the context features of the failed test tasks; and an output section, configured to output aggregate information based on the context features of multiple failed test tasks whose similarity is greater than a similarity threshold, wherein the aggregate information is used to indicate that the failure reasons of multiple failed test tasks are the same.

[0137] In some embodiments, the predefined parsing rules are regular expressions, and different EDA tool types correspond to different feature character sets; wherein, the feature character set corresponding to the memory built-in self-test tool includes characters that characterize memory repair failure; the feature character set corresponding to the formal verification tool includes characters that characterize proof failure; and the feature character set corresponding to the timing simulation tool includes characters that characterize waveform mismatch.

[0138] In some embodiments, the DFT process monitoring apparatus further includes a generation section configured to generate a time-stacked bar chart in a GUI based on the colors associated with the final execution status of each test task, wherein the horizontal axis of the time-stacked bar chart represents the time period or milestone version, and the vertical axis represents the number of test tasks.

[0139] In some embodiments, the DFT process monitoring device further includes: a filtering section configured to, in response to a received selection operation on a target scene view template, filter out a set of test tasks associated with the target scene view template based on preset filtering rules; and a display section configured to, in a two-dimensional grid constructed with design modules as row indices and test steps as column indices, render the corresponding cell in the test task set with a color associated with the final execution state according to the final execution state of each test task in the test task set; and generate a time-stacked bar chart in the GUI according to the color associated with the final execution state of each test task in the test task set, wherein the horizontal axis of the bar chart is the time period or milestone version, and the vertical axis is the number of test tasks in the test task set.

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

[0141] refer to Figure 11 This 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 capabilities 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.

[0142] like Figure 11 As shown, the electronic device in this disclosure may include one or more of the following components: processor 1110 and memory 1120.

[0143] Optionally, the processor 1110 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 1120, and by calling data stored in the memory 1120. Optionally, the processor 1110 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 1110 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 1110, but may be implemented using a separate chip.

[0144] The memory 1120 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 1120 may include a non-transitory computer-readable storage medium. The memory 1120 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 1120 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.

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

[0146] This disclosure also provides a computer-readable storage medium storing at least one instruction that is executed by a processor to implement the DFT process monitoring method as described in the various embodiments above.

[0147] 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 DFT process monitoring method described in the above embodiments.

[0148] 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 DFT process monitoring method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

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

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

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

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

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

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

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

[0156] 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.< / num> < / time> < / addr> < / path> < / time>

Claims

1. A method for monitoring the process of DFT, characterized in that, The process monitoring method for the DFT includes: In response to the detected completion of the current test task, the process status and the current log file generated during the execution of the current test task are obtained; By mapping the EDA tool types to predefined parsing rules, the target predefined parsing rule corresponding to the type of EDA tool used to execute the current test task is determined. Semantic keywords are parsed from the current log file using the predefined parsing rules for the target. Based on the process state and the semantic keywords, determine the final execution state of the current test task; Based on the final execution status of all test tasks included in each test step, a health index for the corresponding test step is determined. The health index includes the current pass rate and the overall pass rate. The current pass rate is the ratio of the number of test tasks that have passed in the final execution status to the total number of test tasks that have been executed. The overall pass rate is the ratio of the number of test tasks that have passed in the final execution status to the total number of test tasks that are planned to be executed.

2. The DFT process monitoring method according to claim 1, characterized in that, The process monitoring method for the DFT includes: Get the current turning point threshold corresponding to the current milestone; Based on the current turning point threshold, the color value corresponding to the health index is determined by a nonlinear color mapping algorithm. The icons representing the health indicators are rendered and displayed on the graphical user interface (GUI) according to the color values.

3. The DFT process monitoring method according to claim 2, characterized in that, The step of determining the color value corresponding to the health index based on the current turning point threshold using a nonlinear color mapping algorithm includes: When the health index is less than or equal to the current turning threshold, the generated color value gradually changes within the first color range, and the rate of change of the color value is proportional to the ratio of the health index to the current turning threshold. When the health index is greater than the current turning point threshold, the generated color value gradually changes within the second color range, and the rate of change of the color value is proportional to the ratio of the complement of the health index to the complement of the current turning point threshold.

4. The DFT process monitoring method according to claim 1, characterized in that, Determining the final execution state of the current test task based on the process state and the semantic keywords includes: If the process status indicator is running, then the final execution status is determined to be unknown; If the process status indicates abnormal termination, then the final execution status is determined to be a failure. If the process status indicates normal termination and the semantic keyword includes a predefined semantic pattern representing a logical error, then the final execution status is determined to be a failure. If the process status indicates normal termination and the semantic keywords do not include predefined semantic patterns representing logical errors, then the final execution status is determined to be passed.

5. The DFT process monitoring method according to claim 1, characterized in that, The DFT process monitoring method also includes: Obtain the contextual features that caused the failure from the log file corresponding to the test task whose final execution status is failure; Determine the similarity between contextual features of failed test tasks; Based on the contextual features of multiple failed test tasks with a similarity greater than a similarity threshold, aggregated information is output, which indicates that the multiple failed test tasks have the same reason for failure.

6. The DFT process monitoring method according to claim 1, characterized in that, The predefined parsing rules are regular expressions, and different EDA tool types correspond to different feature character sets; Among them, the feature character set corresponding to the built-in self-test tool of the memory includes characters that characterize memory repair failure; The feature character set corresponding to the formal verification tool includes characters that represent proof failure; The feature character set corresponding to the timing simulation tool includes characters that represent inconsistencies in waveform comparison.

7. The DFT process monitoring method according to claim 1, characterized in that, The DFT process monitoring method also includes: Based on the color associated with the final execution status of each test task, a time-stacked bar chart is generated in the GUI. The horizontal axis of the time-stacked bar chart represents the time period or milestone version, and the vertical axis represents the number of test tasks.

8. The DFT process monitoring method according to claim 1, characterized in that, The DFT process monitoring method also includes: In response to the received selection operation of the target scene view template, a set of test tasks associated with the target scene view template is selected based on preset filtering rules; In a two-dimensional grid constructed with design modules as row indices and test steps as column indices, the corresponding cell is rendered with a color associated with the final execution state, based on the final execution state of each test task in the test task set. Based on the color associated with the final execution status of each test task in the test task set, a time-stacked bar chart is generated in the GUI. The horizontal axis of the bar chart represents the time period or milestone version, and the vertical axis represents the number of test tasks in the test task set.

9. A process monitoring device for DFT, characterized in that, The DFT process monitoring device includes: an acquisition part, a determination part, and a parsing part; The acquisition section is configured to acquire the process status and the current log file generated during the execution of the current test task in response to the detected completion of the current test task. The determining part is configured to determine the target predefined parsing rule corresponding to the type of EDA tool used to execute the current test task by means of the mapping relationship between the EDA tool type and the predefined parsing rule; The parsing section is configured to parse semantic keywords from the current log file using the target predefined parsing rules; The determining component is further configured to determine the final execution state of the current test task based on the process state and the semantic keywords; and, Based on the final execution status of all test tasks included in each test step, a health index for the corresponding test step is determined. The health index includes the current pass rate and the overall pass rate. The current pass rate is the ratio of the number of test tasks that have passed in the final execution status to the total number of test tasks that have been executed. The overall pass rate is the ratio of the number of test tasks that have passed in the final execution status to the total number of test tasks that are planned to be executed.

10. An electronic device, characterized in that, It includes 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 DFT process monitoring method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the DFT process monitoring method as described in any one of claims 1 to 8.

Images