Method, system, device, medium for verifying a subsystem-level excitation sequence

By generating accurate stimulus sequences through signal tracing and code reconstruction modules, the problem of stimulus sequence redundancy in subsystem-level verification is solved, efficient activation of uncovered points is achieved, and verification efficiency is improved.

CN122389760APending Publication Date: 2026-07-14NATIONAL CENTER OF TECHNOLOGY INNOVATION FOR EDA +1
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
NATIONAL CENTER OF TECHNOLOGY INNOVATION FOR EDA
Filing Date
2026-04-08
Publication Date
2026-07-14

Smart Images

  • Figure CN122389760A_ABST
    Figure CN122389760A_ABST
Patent Text Reader

Abstract

The application provides a verification method, system, device and medium of a subsystem-level excitation sequence, and relates to register transfer level verification technology; wherein the method comprises: inputting an initial target signal set and a subsystem design file set into a signal tracking module, obtaining a global dependency statement set through single-file signal dependency backtracking or cross-file recursive dependency backtracking; wherein the initial target signal is obtained based on uncovered point information; inputting the global dependency statement set into a code structure reconstruction module, eliminating irrelevant codes in the global dependency statement set and completing syntax completion to obtain a filtered design; the filtered design is a design file containing only the causal correlation logic of the initial target signal; inputting the filtered design and the initial target signal set into an excitation generation module to obtain an excitation sequence for the uncovered point; and performing subsystem-level register transfer level verification based on the excitation sequence. Through the method of the application, the uncovered point activation efficiency can be effectively improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to register transfer level verification technology, and more particularly to a method, system, device, and medium for verifying subsystem-level excitation sequences. Background Technology

[0002] In the field of register-transfer level verification technology, the complexity of subsystem-level design continues to increase, and there are a large number of uncovered points in the verification process. The effective activation of these uncovered points is the key to ensuring the correctness of chip design and reducing mass production risks.

[0003] Currently, for the generation and verification of subsystem-level stimulus sequences, the industry mostly relies on manual analysis of design documents associated with uncovered points to sort out signal logic, or uses general tools to perform a full signal dependency scan of the design documents to extract signal logic information related to uncovered points. After obtaining the signal logic information, stimulus sequences are mostly generated based on a preset fixed rule base. Some solutions will use models to generate stimulus sequences. After generation, the stimulus sequences are directly put into the subsystem-level verification environment for simulation verification, and the activation status of uncovered points is judged based on the simulation results.

[0004] However, the above process leads to a lot of redundancy in the input logic for generating the stimulus sequence, resulting in low activation efficiency of uncovered points. Summary of the Invention

[0005] This application provides a method, system, device, and medium for verifying subsystem-level stimulus sequences to improve the activation efficiency of uncovered points.

[0006] In a first aspect, this application provides a method for verifying subsystem-level excitation sequences, the method comprising:

[0007] The initial target signal set and the subsystem design file set are input into the signal tracing module. Through single-file signal dependency tracing or cross-file recursive dependency tracing, a global dependency statement set is obtained. The initial target signal is obtained based on the information of uncovered points.

[0008] The global dependency statement set is input into the code structure reconstruction module, irrelevant code in the global dependency statement set is removed and syntax completion is performed to obtain the filtered design; the filtered design is a design file that only contains the causal relationship logic of the initial target signal.

[0009] The filtered design and the initial target signal set are input into the excitation generation module to obtain the excitation sequence for the uncovered points;

[0010] Subsystem-level register transfer-level verification is performed based on the stimulus sequence.

[0011] In another possible implementation, the global dependency statement set is obtained through single-file signal dependency tracing or cross-file recursive dependency tracing, including:

[0012] For each initial target signal in the initial target signal set, signal dependency reverse tracing is performed based on each file in the subsystem design file set to extract relevant statements in each file that have a logical causal relationship with the initial target signal, which are used as the single file tracing results for each file.

[0013] The single-file tracing results corresponding to each of the aforementioned files are summarized and merged to obtain the global dependency statement set; or, based on the input and output port signals declared by each of the aforementioned files, cross-file dependency tracing expansion is performed, and the single-file tracing results of each of the aforementioned files are concatenated to obtain the cross-file tracing result corresponding to the initial target signal. Then, in the top-level file corresponding to the subsystem design file set, the cross-file tracing results corresponding to each of the initial target signals are summarized and merged to obtain the global dependency statement set.

[0014] In another possible implementation, the signal dependency back-tracing is performed on each file in the subsystem design file set to extract relevant statements within each file that have a logical causal relationship with the initial target signal, including:

[0015] Initialize the processing queue, the set of visited signals, and the result collector; wherein, the initialized processing queue contains each of the initial target signals in the initial target signal set, and the initialized set of visited signals and the result collector are both empty sets;

[0016] For any file in the subsystem design file set, repeat the following operation until the processing queue is empty, then extract the relevant statements from the result collector as the single-file traceability result of the file:

[0017] Take a signal from the processing queue as a signal to be processed, and add the signal to be processed to the set of accessed signals;

[0018] Based on the signal to be processed, each statement in the file is scanned, and statements in the file that meet the preset rules are added to the result collector as the relevant statements.

[0019] In another possible implementation, the method further includes:

[0020] If the signal to be processed is not in the set of visited signals, then it is determined to add the signal to be processed to the set of visited signals.

[0021] And / or,

[0022] The candidate signals corresponding to the relevant statements are parsed, and the processing queue is updated based on the candidate signals; the candidate signals are other signals that have a logical causal relationship with the file, other than the initial target signal.

[0023] In another possible implementation, the cross-file dependency tracing unrolling based on the input and output port signals declared by each of the files, and the concatenation of the single-file tracing results of each of the files, includes:

[0024] Initialize the current signal set and the global dependency library; wherein, the initialized current signal set contains each of the initial target signals, and the initialized global dependency library is an empty set;

[0025] Repeat the following operation until the current signal set is empty: retrieve the single-file tracing result of the top-level file corresponding to the subsystem design file set, combine it with the input and output port signals to complete the hierarchical mapping, and concatenate the single-file tracing results of each file in the global dependency library to obtain the cross-file tracing result corresponding to the initial target signal:

[0026] For any file in the subsystem design file set, retrieve the single file traceability result corresponding to the file, and merge the single file traceability result into the global dependency library;

[0027] From the single file tracing results, the input and output port signals declared in the file are filtered out.

[0028] In another possible implementation, the method further includes, during each iteration:

[0029] Create a temporary new set of interface signals, and add the selected input and output port signals to the new set of interface signals;

[0030] The new interface signal set is deduplicated, and the current signal set is updated based on the deduplicated new interface signal set to complete the configuration of the tracking basis for the next round of cross-file dependency tracing.

[0031] In another possible implementation, the process of removing irrelevant code from the global dependency statement set and performing syntax completion to obtain the filtered design includes:

[0032] Based on grammatical features, each related statement in the global dependency statement set is classified to obtain at least one set of related statements;

[0033] For each set of related statements, select the template with the highest fit from the preset template library as the target template;

[0034] The target template is populated based on the relevant statements, and the populated target templates are integrated to obtain the filtered design.

[0035] In another possible implementation, selecting the template with the highest adaptability from a preset template library as the target template includes:

[0036] The grammatical features corresponding to each group of related statements are compared with the grammatical matching features of each template in the preset template library, and the feature matching degree is calculated.

[0037] The template with the highest feature matching degree is determined as the target template.

[0038] In another possible implementation, the syntax features include at least one of keywords, assignment types, and structural information of the original file; and / or, the preset template library includes at least one of continuous assignment templates, conditional branch templates, selection statement templates, procedure block templates, and generator block templates.

[0039] In another possible implementation, the step of inputting the filtered design and the initial target signal set into the excitation generation module to obtain the excitation sequence for the uncovered points includes:

[0040] Based on the filtered design, the initial target signal set, and the preset verification engineering constraints, a structured task instruction package is constructed; the structured task instruction package includes model role positioning, core tasks of stimulus sequence generation, standardized technical constraints, and contextual information related to the filtered design.

[0041] Based on the structured task instruction package, repeat the following process until the coverage reaches a preset threshold and / or the number of iterations reaches a preset number, then stop the iteration and obtain the stimulus sequence:

[0042] The structured task instruction package is sent to the large language model to generate an initial excitation sequence for the uncovered points corresponding to the initial target signal set;

[0043] The initial stimulus sequence is integrated into the subsystem-level test environment. Compilation and simulation verification are completed based on the original design code corresponding to the subsystem design file set, and the current verification coverage is collected synchronously.

[0044] If an error is detected in the initial stimulus sequence during the verification process, the diagnostic information corresponding to the error is captured and fed back to the large language model to obtain the cause of the defect and repair, optimize or regenerate the initial stimulus sequence based on the cause of the defect, and use the corrected stimulus sequence as the new initial stimulus sequence.

[0045] If the initial stimulus sequence is found to have completed compilation and simulation verification without errors, the verification coverage is updated based on the original design code, and the iteration count is updated synchronously.

[0046] In another possible implementation, the step of inputting the filtered design and the initial target signal set into the excitation generation module to obtain the excitation sequence for the uncovered points includes:

[0047] At least two heterogeneous large language models are invoked in parallel to obtain corresponding candidate excitation sequences based on the filtered design and the initial target signal set, respectively.

[0048] The stimulus sequence is determined based on each of the candidate stimulus sequences.

[0049] In another possible implementation, the method further includes:

[0050] The large language model combines the causal relationship logic designed after filtering with the information of uncovered points corresponding to the initial target signal set to infer whether the uncovered points can be activated by legitimate stimuli.

[0051] If it is inferred that the uncovered point cannot be activated by a legitimate incentive due to design limitations, an exemption suggestion is generated; the exemption suggestion is presented in the form of structured annotations, clearly indicating the reasons for the exemption and the corresponding design logic basis;

[0052] Based on the aforementioned exemption recommendations, an exemption report is generated and marked in the coverage database for use in the subsequent collection and updating of coverage to exclude uncovered points for reasonable exemptions.

[0053] In another possible implementation, generating an exemption report based on each of the exemption recommendations includes:

[0054] Collect all the aforementioned exemption suggestions to generate an exemption candidate point report, and submit the exemption candidate point report to the manual review stage;

[0055] If the exemption candidate point is confirmed as a reasonable exemption by manual review, then the exemption candidate point is marked in the coverage database by an automated script;

[0056] Accordingly, the method further includes:

[0057] If the manual review determines that the exemption candidate point is unreasonable, the review opinion will be fed back to the large language model, which will then optimize the incentive sequence generation logic based on the review opinion and continue to execute the incentive sequence generation and iteration process.

[0058] Secondly, this application provides a subsystem-level excitation sequence verification apparatus, the apparatus comprising:

[0059] The tracing module is used to input the initial target signal set and the subsystem design file set into the signal tracing module, and obtain the global dependency statement set through single-file signal dependency tracing or cross-file recursive dependency tracing; wherein, the initial target signal is obtained based on the information of the uncovered points;

[0060] The reconstruction module takes the set of global dependency statements as input to the code structure reconstruction module, removes irrelevant code from the set of global dependency statements and completes syntax auto-completion to obtain the filtered design; the filtered design is a design file that only contains the causal relationship logic of the initial target signal.

[0061] The generation module is used to input the filtered design and initial target signal set into the excitation generation module to obtain the excitation sequence for the uncovered points;

[0062] The verification module is used to perform subsystem-level register transfer-level verification based on the stimulus sequence.

[0063] Thirdly, this application provides a subsystem-level excitation sequence verification system, the system comprising:

[0064] The signal tracing module is used to obtain a global dependency statement set based on an initial target signal set and a subsystem design file set, through single-file signal dependency tracing or cross-file recursive dependency tracing; wherein, the initial target signal is obtained based on uncovered point information;

[0065] The code structure reconstruction module is used to obtain the global dependency statement set, remove irrelevant code from the global dependency statement set and complete the syntax, and obtain the filtered design; the filtered design is a design file that only contains the causal relationship logic of the initial target signal.

[0066] The excitation generation module is used to obtain an excitation sequence for the uncovered points based on the filtered design and the initial target signal set.

[0067] The verification module is used to perform subsystem-level register transfer-level verification based on the stimulus sequence.

[0068] Fourthly, this application provides an electronic device, comprising: at least one processor and a memory;

[0069] The memory stores computer-executed instructions;

[0070] The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the method as described in any of the first aspects above.

[0071] Fifthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a central processing unit, are used to implement the method described in any of the first aspects above.

[0072] Sixthly, this application provides a computer program product including a computer program that, when executed by a central processing unit, implements the method described in any of the first aspects.

[0073] This application provides a method, system, device, and medium for verifying subsystem-level stimulus sequences. The method proposes determining an initial target signal set based on uncovered point information. This initial target signal set, along with a set of subsystem design files, is input into a signal tracing module. A global dependency statement set is extracted through single-file signal dependency tracing or cross-file recursive dependency tracing. A code structure reconstruction module then removes irrelevant code and completes syntax to obtain a filtered design containing only the causal relationship logic of the initial target signals. Finally, the filtered design and the initial target signal set are input into a stimulus generation module to obtain a stimulus sequence for the uncovered points. Subsystem-level register transfer level verification is then performed based on this stimulus sequence. In this process, the signal tracing step accurately identifies the core signal logic associated with the uncovered points, avoiding redundant information interference from full scans. The code structure reconstruction step further removes irrelevant code and optimizes logical integrity, ensuring that the stimulus generation module generates stimulus sequences based only on pure logic strongly correlated with the uncovered points. This reduces the generation of invalid stimuli from the source, ensuring that the generated stimulus sequence accurately targets the activation requirements of the uncovered points, thereby effectively improving the activation efficiency of the uncovered points. Attached Figure Description

[0074] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0075] Figure 1 A schematic diagram illustrating an application scenario for a subsystem-level excitation sequence verification method provided in this application embodiment;

[0076] Figure 2 A flowchart illustrating a subsystem-level stimulus sequence verification method provided in this application embodiment. Figure 1 ;

[0077] Figure 3 An example diagram illustrating code structure reconstruction provided in this application embodiment;

[0078] Figure 4 A flowchart illustrating a subsystem-level stimulus sequence verification method provided in this application embodiment. Figure 2 ;

[0079] Figure 5 A schematic diagram illustrating the principle of a subsystem-level excitation sequence verification method provided in this application embodiment;

[0080] Figure 6 A comparative illustration of the effectiveness of a subsystem-level stimulus sequence verification method provided in this application embodiment;

[0081] Figure 7 A schematic diagram of the structure of a subsystem-level excitation sequence verification device provided in an embodiment of this application;

[0082] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0083] Figure 9 This is a schematic diagram of the structure of a subsystem-level excitation sequence verification system provided in an embodiment of this application.

[0084] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0085] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0086] In the field of register-transfer level verification technology, with the continuous increase in chip integration and functional complexity, the logic links of subsystem-level circuit designs are becoming increasingly complex, involving massive signal interactions and module relationships. This inevitably leads to a large number of uncovered functional points, boundary-level uncovered points, and abnormal scenario-level uncovered points during the verification process. The effective activation of these uncovered points is directly related to the accurate identification of chip design defects. It is a core and critical step in ensuring the correctness and stability of chip design functions, avoiding failure risks in the mass production stage, and reducing subsequent rectification costs. Its activation efficiency and activation quality directly determine the overall progress and effectiveness of subsystem-level verification.

[0087] Currently, the mainstream implementation methods for generating and verifying subsystem-level stimulus sequences in the industry are mainly divided into two categories: one is a manual logic sorting and stimulus generation mode, in which verification personnel need to analyze the design documents associated with uncovered points line by line, manually sort out the causal dependencies of signals, filter out the logical information of related signals, and then generate stimulus sequences by writing scripts or calling basic tools based on project experience and verification requirements; the other is to use general verification tools for automated processing, by performing indiscriminate signal dependency scanning on the entire quantum system design documents, extracting the logical information of all signals in batches, and then roughly filtering the related logic based on uncovered points. After obtaining the signal logical information, either the stimulus sequence is generated based on a preset fixed rule base (such as stimulus templates for common scenarios, signal assignment rules, etc.), or the extracted logical information is directly processed with the help of a basic model to generate stimuli. Regardless of the method, after generating the stimulus sequence, it is directly put into the subsystem-level verification environment for simulation, and the activation of uncovered points is determined only by the final simulation coverage data and simulation logs.

[0088] However, the aforementioned manual sorting method is prone to incomplete logic extraction and low efficiency due to high design complexity and cumbersome signal associations. On the other hand, a full scan by general tools will indiscriminately extract a large amount of redundant logic unrelated to uncovered points (such as signal interaction logic of non-associated modules, redundant assignment statements, etc.). At the same time, neither the fixed rule base nor the basic model performs targeted simplification and optimization of the extracted signal logic, directly using logic containing a large amount of redundant information as input for stimulus generation. This results in a large amount of redundancy in the input logic of stimulus sequence generation. The generated stimulus sequence often contains a lot of invalid stimuli unrelated to the activation of uncovered points. This not only increases the computational load and time consumption of stimulus generation, but also makes it impossible for the stimulus sequence to accurately match the activation requirements of uncovered points, ultimately resulting in low efficiency in the activation of uncovered points.

[0089] Therefore, this application provides a method, system, device, and medium for verifying subsystem-level stimulus sequences to at least solve the aforementioned problem of low efficiency. Specifically, the subsystem-level stimulus sequence verification method of this application proposes to perform signal dependency tracing processing on the initial target signal set and the subsystem design file set obtained based on the information of uncovered points using a signal tracing module. It selects either single-file signal dependency tracing or cross-file recursive dependency tracing to obtain a global dependency statement set. Then, a code structure reconstruction module performs irrelevant code removal and syntax completion processing on the global dependency statement set to obtain a filtered design that retains only the causal relationship logic of the initial target signals. Subsequently, the filtered design and the initial target signal set are input into an stimulus generation module to generate a dedicated stimulus sequence for uncovered points. Finally, a subsystem-level register transfer level verification is performed based on this stimulus sequence, achieving efficient activation of uncovered points.

[0090] It should be understood that the method of this application can be executed by any electronic device and applied in any register-transfer level subsystem-level design verification scenario. As an example, Figure 1 This is a schematic diagram illustrating an application scenario for a subsystem-level stimulus sequence verification method provided in an embodiment of this application. Figure 1 As shown, the subsystem-level stimulus sequence verification method of this application can be applied to subsystem-level functional verification scenarios in the integrated circuit design process. In this scenario, it is necessary to perform full-coverage verification of the register transfer level design code of the chip subsystem. Traditional methods suffer from redundant stimulus generation input logic, resulting in long activation times for uncovered points and slow verification progress.

[0091] like Figure 1 As shown, the electronic device interacts with the subsystem-level verification platform. Based on the verification method of this application, the electronic device obtains information on uncovered points and a set of subsystem design files from the subsystem-level verification platform. First, it performs single-file or cross-file signal dependency tracing through the built-in signal tracing module to obtain a set of global dependency statements. Then, the code structure reconstruction module removes irrelevant code, completes syntax completion, and generates filtered designs. Subsequently, the stimulus generation module generates stimulus sequences for the uncovered points and sends these stimulus sequences to the subsystem-level verification platform, which then performs subsystem-level register transfer level verification based on the stimulus sequences.

[0092] In this embodiment, the electronic device serves as the core processing unit, undertaking the core computational tasks of signal tracing, code reconstruction, and stimulus generation. The subsystem-level verification platform undertakes the simulation verification of the stimulus sequence and the feedback of activation results of uncovered points. The two work together to complete the full-process verification at the subsystem level.

[0093] With the above settings, the stimulus sequence sent by the electronic device to the subsystem-level verification platform no longer contains invalid and redundant content. It can directly and accurately target the activation requirements of uncovered points, so that the subsystem-level verification platform does not need to spend computing power and time to perform simulation calculations on invalid stimuli. It also avoids redundant operations such as repeated simulation and regeneration of stimuli due to insufficient stimulus adaptability. This can shorten the activation time of a single uncovered point, increase the number of uncovered points activated per unit time, effectively accelerate the overall progress of subsystem-level functional verification, and fundamentally improve the activation efficiency of uncovered points in register transfer level verification scenarios.

[0094] It is understood that the electronic device can be any device such as a server, workstation, or industrial computer, and this application does not limit it. Furthermore, the electronic device and the subsystem-level verification platform can be deployed independently, integrated on the same hardware platform, or converged through virtualization technology, and this application does not limit them either. In addition to the above application scenarios, the method of this application can also be used for register-transfer level subsystem verification scenarios of various chip designs, such as subsystem-level verification of high-end processors, application-specific integrated circuits, and systems-on-a-chip, and this application does not limit them either.

[0095] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Where the embodiments do not conflict, the following embodiments and features thereof can be combined with each other.

[0096] This application provides a method for verifying subsystem-level stimulus sequences, specifically executed by any electronic device. Figure 2 A flowchart illustrating a subsystem-level stimulus sequence verification method provided in this application embodiment. Figure 1 ,like Figure 2 As shown, the method provided in this embodiment includes:

[0097] S201: Input the initial target signal set and the subsystem design file set into the signal tracing module, and obtain the global dependency statement set through single-file signal dependency tracing or cross-file recursive dependency tracing.

[0098] The initial target signal is obtained based on information about uncovered points.

[0099] It should be understood that the execution timing of the method in this application can run through the entire process of subsystem-level register transfer level verification. It is especially suitable for scenarios where a targeted stimulus sequence needs to be generated to activate the uncovered points after an uncovered point (including functional uncovered points, boundary uncovered points, abnormal scenario uncovered points, etc.) is detected during the verification process. It can be executed in the centralized processing stage of a batch of uncovered points or in the separate verification stage of a single uncovered point, flexibly adapting to different verification progress requirements.

[0100] Based on this, in this embodiment, the electronic device obtains simulation verification logs, coverage reports, and other data from the subsystem-level verification platform, and filters out uncovered point information by parsing the aforementioned data. The uncovered point information includes core information such as the functional module corresponding to the uncovered point, the signal interaction path, and the triggering conditions. Subsequently, based on the uncovered point information, combined with the functional requirements of the subsystem design and signal association rules, signals directly related to the activation of uncovered points are filtered out, such as input signals triggering uncovered scenarios, key intermediate signals in uncovered logic links, and output signals corresponding to uncovered functions. These signals are then organized into an initial target signal set.

[0101] In this embodiment, the electronic device retrieves the original design code (such as register-transfer level code like Verilog or VHDL) of the subsystem from a chip design database or version management system. After parsing the original design code, splitting it into modules, and preprocessing redundant code (only removing non-functional redundancy such as comments and blank lines without changing the core logic), a set of subsystem design files is obtained, containing one top-level module file and multiple bottom-level submodule files. It should be understood that this file set is a standardized and encapsulated version of the original design code, completely consistent with the core logic of the original design code, with only the file organization optimized to suit the processing requirements of the signal tracing stage.

[0102] In this embodiment, the signal tracing module is a core functional module built into the electronic device. It has capabilities such as signal dependency parsing, statement extraction and filtering, and can automatically match an appropriate tracing method based on the input initial target signal set and subsystem design file set. Specifically, in this embodiment, the electronic device uses the initial target signal set and subsystem design file set as input to the signal tracing module. The signal tracing module adopts a hierarchical recursive strategy, and its core workflow consists of two cooperating algorithms: a single-file signal dependency tracing algorithm and a cross-file recursive dependency tracing algorithm.

[0103] More specifically, when the signal logic corresponding to the uncovered point is limited to a single design file (such as the independent logic of a functional submodule) and the signal interaction is not related across files, the signal tracing module uses a single-file signal dependency tracing method to traverse the signal definitions and logic statements in that single design file, extracting all statements that have a direct or indirect causal relationship with the initial target signal, forming a global dependency statement set. When the signal logic corresponding to the uncovered point involves multiple design files (such as signal interaction logic across modules or subsystems), and the signal needs to be transmitted between multiple design files to trigger related logic, the signal tracing module uses a cross-file recursive dependency tracing method, starting from the initial target signal, to trace the signal dependency relationships in each related design file layer by layer, recursively extracting all relevant logic statements, and finally integrating them to form a global dependency statement set.

[0104] The global dependency statement set is the core data output by the signal tracing module after tracing. It is a set of logical statements that are causally related to the initial target signal (i.e., the signal related to the activation of the uncovered point). It does not contain redundant statements that are unrelated to the activation of the uncovered point (such as independent logical statements of other functional modules, signal assignment statements that do not participate in the link of the uncovered point, etc.). Its core function is to provide accurate logical input for subsequent code structure reconstruction and stimulus sequence generation, and to ensure that the stimulus sequence generation focuses only on the activation requirements of the uncovered point.

[0105] As an example, for each initial target signal in the initial target signal set, the electronic device performs signal dependency reverse tracing based on each file in the subsystem design file set, extracting relevant statements in each file that have a logical causal relationship with the initial target signal, as the single-file tracing result for each file; the single-file tracing results for each file are summarized and merged to obtain a global dependency statement set; or, based on the input and output port signals declared in each file, cross-file dependency tracing expansion is performed, the single-file tracing results of each file are concatenated to obtain the cross-file tracing result corresponding to the initial target signal, and then in the top-level file corresponding to the subsystem design file set, the cross-file tracing results corresponding to each initial target signal are summarized and merged to obtain a global dependency statement set.

[0106] Specifically, for each initial target signal in the initial target signal set, the electronic device first uses the logical causal relationship of that signal as the tracing basis. It independently initiates a signal dependency reverse tracing process in each file of the subsystem design file set, starting from the initial target signal and tracing back layer by layer the signal's assignment source, logical driving relationship, and definition statements. It then filters out all relevant statements within the file that have a direct or indirect logical causal relationship with the initial target signal, using these as the single-file tracing result for that file. After completing the single-file tracing of all files, the electronic device determines whether a direct causal relationship exists based on the file association relationship of the subsystem design file set and the cross-file propagation characteristics of the initial target signal. By combining the single-file tracing results, if it is determined that the logical link of the initial target signal does not extend across files and the single-file tracing results of each file have no port signal association interaction, then the single-file tracing results corresponding to each file are directly summarized and merged to obtain a global dependency statement set; if it is determined that the logical link of the initial target signal involves cross-file interaction and there is a driving and driven relationship between input and output port signals between files, then cross-file dependency tracing expansion is further performed based on the input and output port signals declared by each file to establish the port association relationship of the single-file tracing results of different files, and the complete cross-file logical link is formed by connecting them to obtain the cross-file tracing results corresponding to each initial target signal.

[0107] In practical applications, electronic devices can also determine whether to perform single-file signal dependency tracing or cross-file recursive dependency tracing on the initial target signal based on the module identifier of the subsystem design file, the module information to which the initial target signal belongs, and the preset cross-file signal association judgment rules. This embodiment does not limit this.

[0108] In this embodiment, basic logic statements are first accurately extracted through single-file reverse tracing, signal by signal and file by file, ensuring the integrity and accuracy of signal dependency tracing within a single file. Then, cross-file tracing is flexibly switched through file port signals, which can quickly merge results to improve tracing efficiency when there is no cross-file logic, and can completely connect cross-file links when there is cross-file logic, ensuring the integrity of the global dependency statement set. At the same time, the cross-file tracing results are integrated with the top-level file as the summary node, which fits the top-level-bottom-level module architecture characteristics of the subsystem-level design. This makes the generation of the global dependency statement set more in line with the logical organization of the original subsystem design, providing clear and logically complete input data for the subsequent code structure reconstruction stage. This effectively avoids the problem of missing or redundant extraction of logic statements during the tracing process, further improving the accuracy and efficiency of signal tracing and ensuring the input quality of subsequent stimulus sequence generation.

[0109] Furthermore, in practical applications, electronic devices can first cluster and group the initial target signal set. Specifically, according to the functional module to which the signal belongs (such as a data processing module, control module, interface module, etc.) or the logical link in which the signal participates (such as a complete signal interaction link corresponding to a certain uncovered point), the initial target signal set can be split into multiple independent sub-target signal sets. Then, for each sub-target signal set, it is determined whether the logic of the signal in that set is limited to a single file or whether cross-file interaction is required. Then, the single-file signal dependency tracing or cross-file recursive dependency tracing method is matched, and the signal dependency tracing is completed group by group to obtain the corresponding dependency statement subset for each group. Finally, the dependency statement subsets of all groups are integrated, and duplicate logical statements are removed to form a global dependency statement set.

[0110] In practical applications, electronic devices can first divide the subsystem design file set into module levels, such as from the bottom-level basic submodule file, to the middle-level functional integration module file, and then to the top-level system overview module file. Then, starting from the bottom-level submodule file, signal dependency tracing is performed layer by layer upwards. During the tracing process, if the signal logic of a certain level is only in a single file, single-file signal dependency tracing is used; if cross-file interaction is required (such as from the bottom-level submodule file to the middle-level module file), cross-file recursive dependency tracing is switched to gradually extract and summarize the logical statements related to the initial target signal. After traversing all levels, a global dependency statement set is finally formed.

[0111] This application does not limit this, as long as it can accurately extract all logical statements that have a direct or indirect causal relationship with the initial target signal based on the initial target signal set and the subsystem design file set, and integrate them into a global dependency statement set through the core technical means of single file signal dependency tracing or cross-file recursive dependency tracing.

[0112] As a further design, when the electronic device obtains the single file tracing result based on the single file signal dependency tracing algorithm, the electronic device first initializes the processing queue, the set of accessed signals, and the result collector; wherein, the initialized processing queue contains each initial target signal in the initial target signal set, and the initialized set of accessed signals and the result collector are both empty sets.

[0113] Subsequently, for any file in the subsystem design file set, the following operation is repeated until the processing queue is empty. When the processing queue is empty, the relevant statements in the result collector are extracted as the single file traceability results of the file: a signal is taken from the processing queue as a signal to be processed and added to the set of accessed signals; based on the signal to be processed, each statement in the file is scanned to obtain the statements in the file that meet the preset rules and add them to the result collector as relevant statements.

[0114] Specifically, in this embodiment, during the initialization phase, the electronic device creates a first-in-first-out (FIFO) queue to store the initial target signals whose dependencies are to be analyzed. It should be understood that during the initialization phase, this FIFO queue should contain all initial target signals from the initial target signal set. Simultaneously, the electronic device creates an accessed set and a result collector. The accessed set records signals that have already been processed to prevent repeated analysis of the same signal and avoid infinite loops. The result collector is also a set that stores all statements identified as related to the initial target signals (in this embodiment, these are Verilog statements, such as assign statements, assignment statements within always blocks, etc.). After initialization, both sets are empty.

[0115] During the iterative tracing phase, the electronic device uses an empty processing queue as the termination condition. While the processing queue is not empty, the following loop is repeated: The electronic device retrieves a signal from the head of the processing queue as a signal to be processed and places it into the visited set. Subsequently, based on the signal to be processed, the current file is scanned. The electronic device traverses all logical statements within the file line by line, identifying whether each statement contains the signal identifier of the signal to be processed. Simultaneously, it parses the logical relationship between the statement and the signal to be processed, filters statements that meet preset rules as relevant statements, and places these relevant statements into the result collector.

[0116] In this embodiment, the preset rule is that the statement directly references the signal to be processed as an operand, assignment target, or component of a conditional expression, or indirectly associates the signal to be processed through signal aliases or bit width truncation, and the statement and the signal to be processed have a direct logical causal relationship.

[0117] In practical applications, the processing queue can also be other types of queue structures such as last-in-first-out queues and priority queues, as long as it can achieve the orderly storage and retrieval of signals to be processed and adapt to the iterative processing requirements of single-file signal dependency tracing; the iteration termination condition can also be that the set of accessed signals contains all associated signals in the file, or that the number of statements in the result collector no longer increases; the preset rules can also be adapted and adjusted according to the type of register transfer level design language and the form of signal association, such as only determining the direct reference relationship between statements and signals to be processed, or adding differentiated association determination rules for internal connection signals and register signals of modules, etc., which are not limited in this embodiment.

[0118] It should be understood that through the above iterative process, a single file traceability result for the initial target signal set can be obtained. For each file in the subsystem design file set, the electronic device independently executes the above initialization and iterative traceability process, and finally obtains the single file traceability result corresponding to each file in the subsystem design file set. The traceability results of each file are independent of each other, and only the logical statements related to the initial target signal set within its own file are collected.

[0119] In this embodiment, the automated and standardized execution of signal dependency tracing within a single file is achieved through standardized initialization and iterative tracing processes. The first-in-first-out queue design ensures the sequentiality of signal tracing, and the setting of the visited set avoids the problems of repeated analysis and circular tracing from the root. The result collector enables the precise collection of relevant statements, making the extraction of single-file tracing results more efficient and accurate. At the same time, the fixed iteration logic also improves the portability of the algorithm and can adapt to the parsing requirements of different types of register transfer level design files.

[0120] As a preferred example, in each iteration described above, after the electronic device retrieves a signal from the processing queue as the signal to be processed, it first performs a repeated check on the signal to be processed to see if the signal is already in the visited set. If the signal to be processed is not in the visited signal set, it is determined to add the signal to be processed to the visited signal set.

[0121] Specifically, the electronic device compares the unique identifier of the signal to be processed with all the signal identifiers stored in the accessed set one by one. If there is a completely matching identifier, it is determined that the signal to be processed has been in the accessed set; if there is no matching identifier, it is determined that the signal to be processed has not been accessed.

[0122] It should be understood that in practical applications, a hash index can be established for the visited set, and the identifier of the signal to be processed can be hashed and the existence of a matching item can be quickly queried through the index; or an access status flag can be set for each signal, and the status of the flag can be read to directly determine whether the signal to be processed has been visited. This embodiment does not limit this.

[0123] As a preferred example, in each iteration described above, the electronic device adds the relevant statements to the result collector, parses the candidate signals corresponding to the relevant statements, and updates the processing queue based on the candidate signals. The candidate signals are signals that, besides the initial target signal, have a logical causal relationship with the file.

[0124] Specifically, the electronic device performs syntax parsing on the newly added relevant statements in the result collector, extracts all signal identifiers within the statements and forms a signal set, removes the initial target signal and the current signal to be processed from the signal set to obtain candidate signals; then it iterates through all candidate signals, adds candidate signals that do not appear in the visited set to the tail of the processing queue according to the first-in-first-out rule, and completes the update of the processing queue.

[0125] Based on the foregoing, as a specific implementation method, the specific iterative process in this embodiment is as follows:

[0126] a. Retrieve Signal: The electronic device retrieves a signal from the head of the processing queue as the signal to be processed.

[0127] b. Repeat check: Check if the signal to be processed is already in the "visited set". If so, skip the signal to be processed and continue processing the next signal in the queue.

[0128] c. Tagging and Recording: Add the signal to the "Visited Set".

[0129] d. File scanning: Scan the current file line by line. For each statement, determine whether it is a relevant statement based on the preset rule of "whether the statement references the currently being processed signal, whether as an operand, assignment target, or part of a conditional expression".

[0130] e. Update the results collector: Add all relevant statements that satisfy the above preset rules to the "results collector".

[0131] f. Update the processing queue: Parse all referenced signal identifiers from the relevant statement to form a new signal set; remove the currently being processed signals from this new signal set to obtain a batch of candidate signals; then iterate through these candidate signals and add the signals that have not yet appeared in the "visited set" to the end of the "processing queue" for further analysis.

[0132] It should be understood that, in the above process, if there are no relevant statements in the current file that meet the preset rules, the result collector update and processing queue update steps are skipped directly, and the process queue head is returned to continue to retrieve the next signal for iterative processing.

[0133] It should be understood that in practical applications, candidate signals can also be parsed by the syntax tree of the statement and all signal identifiers can be extracted by traversing the nodes of the syntax tree; alternatively, candidate signals can be parsed by matching the signal identifier information in relevant statements based on a preset signal keyword library. This embodiment does not limit this.

[0134] With the above settings, the repeated checking step filters out visited signals in advance by matching signal identifiers or indexing, avoiding repeated tracing and invalid calculations of the same signal, reducing computational consumption during iteration, and preventing the tracing process from getting stuck due to circular dependencies, thus ensuring the smoothness of single-file tracing. The update processing queue step realizes the layer-by-layer reverse tracing of signal dependencies. Starting from the initial target signal, it continuously mines indirectly related candidate signals by parsing relevant statements, allowing the tracing scope to automatically extend to all signals that have an indirect logical causal relationship with the initial target signal. This ensures the integrity of signal dependency tracing within a single file and ensures that the result collector can collect all logical statements related to the initial target signal, laying the foundation for the accurate extraction of the subsequent global dependency statement set.

[0135] In addition, in practical applications, when performing single-file tracing, all files in the subsystem design file set can be scanned sequentially for each signal to be processed during each iteration, and then operations such as filtering relevant statements, collecting results, and updating the processing queue can be performed for each file. This application does not limit this.

[0136] As a further design, when the electronic device obtains cross-file tracing results by iteratively tracking the interface signals between files in the design file set of the subsystem, the electronic device first initializes the current signal set and the global dependency library; wherein, the initialized current signal set contains each initial target signal, and the initialized global dependency library is an empty set.

[0137] Subsequently, the following operations are repeated until the current signal set is empty. The single-file traceability result of the top-level file corresponding to the subsystem design file set is retrieved, and the hierarchical mapping is completed by combining the input and output port signals. The single-file traceability results of each file in the global dependency library are concatenated to obtain the cross-file traceability result corresponding to the initial target signal. For any file in the subsystem design file set, the single-file traceability result corresponding to the file is retrieved, and the single-file traceability result is merged into the global dependency library. The input and output port signals declared in the file are selected from the single-file traceability results.

[0138] Specifically, in this embodiment, during the initialization phase, the electronic device uses the initial target signal set as the signals to be tracked in the first round of iterations. Simultaneously, an empty set is created as a global dependency library to accumulate relevant statements collected from all files.

[0139] During the hierarchical recursive expansion phase, the electronic device uses the emptiness of the current signal set as the termination condition for iteration. When the current signal set is not empty, the following loop is repeated: The electronic device uses the current signal set as the tracing basis, traverses each file in the subsystem design file set, first retrieves the single-file tracing result that matches the current signal set from the pre-stored single-file tracing result set; then, it completely merges the single-file tracing result into the global dependency library to achieve the accumulation and collection of cross-file related statements; after merging, based on the module definition information and port declaration statements of the file, it filters out the input port signals and output port signals explicitly declared at the module interface of the file from the retrieved single-file tracing results to obtain the interface signal set associated with the file, thus completing the cross-file tracing processing of a single file.

[0140] Similarly, in practical applications, the iteration termination condition can also be that all signals in the current signal set are port signals of the top-level module of the subsystem, or that the number of newly added single-file traceability results in the global dependency library is zero, etc. This embodiment does not limit this.

[0141] In this embodiment, interface signals serve as the core link for cross-file tracing, enabling the automated chaining of signal dependencies among multiple files in the subsystem design file set. The global dependency library ensures the orderly accumulation and unified management of cross-file related statements, avoiding omissions or duplicate merging of statements. Simultaneously, the termination condition of an empty current signal set guarantees the integrity of cross-file tracing. Starting from the initial target signal, it traces layer by layer to all associated underlying module files, ultimately combining the top-level file to complete the hierarchical mapping and result chaining. This ensures that the cross-file tracing results perfectly match the modular design architecture of the subsystem, accurately restoring the complete cross-file logical link corresponding to the initial target signal, and providing a complete and coherent logical input for the subsequent formation of the global dependency statement set.

[0142] As a preferred example, in each iteration, the electronic device creates a temporary new set of interface signals, adds the selected input and output port signals to the new set of interface signals, performs deduplication on the new set of interface signals, updates the current set of signals based on the deduplicated new set of interface signals, and completes the configuration of the tracking basis for the next round of cross-file dependency tracing.

[0143] Specifically, in each iteration, after the electronic device has traversed all files in the subsystem design file set and completed the filtering of the interface signal sets for each file, it first creates a temporary new interface signal set and adds all the input and output port signals filtered from all files to this temporary set. Then, it performs deduplication on the new interface signal set, removing duplicate port signals to obtain a unique interface signal set. Finally, it updates the current signal set directly to this deduplicated new interface signal set, making this unique interface signal set the basis for the next round of cross-file dependency tracing, driving the next round of file traversal and single-file tracing result retrieval operations. The deduplication process is specifically implemented by comparing all port signals in the new interface signal set one by one according to a unique identifier, retaining the unique port signal corresponding to each identifier, and removing the remaining duplicate signal entries.

[0144] In practical applications, deduplication can also be achieved by creating a hash table for the new set of interface signals and using the uniqueness of the hash table to automatically filter duplicate signals; or by grouping and sorting port signals according to module affiliation and signal name, and then removing duplicate signals from each group; or by generating a unique code for each port signal through a preset unique identifier rule, and achieving fast filtering of duplicate signals through code matching. This embodiment does not limit this approach.

[0145] In this embodiment, by creating a temporary new set of interface signals to integrate the interface signals of all files, and performing deduplication processing to update the current signal set, the tracing basis for the next round of cross-file tracing is a set of interface signals without duplication. This avoids repeated tracing of the same interface signal, reduces invalid calculations in the iteration process, and improves the overall efficiency of cross-file tracing. Furthermore, by using the interface signals as clues, the scope of cross-file tracing can be extended layer by layer from the current signal set to the underlying module files of the subsystem, fully excavating all cross-file related logical links behind the initial target signal. This ensures that no cross-file signal dependencies related to uncovered points are missed, fundamentally avoiding the problem of inaccurate activation of uncovered points due to cross-file logical omissions. This guarantees the integrity of the cross-file tracing results and allows the subsequently generated stimulus sequences to accurately match the cross-file activation requirements of uncovered points.

[0146] It should be understood that the aforementioned process involves first performing single-file tracing independently for each file in the subsystem design file set to obtain the corresponding single-file tracing result, and then further integrating or performing cross-file tracing based on the single-file tracing result to finally determine the global dependency statement set. In practical applications, it is also possible to pre-determine whether it is sufficient to perform only single-file tracing for the initial target signal or to perform cross-file tracing based on the attribution characteristics of the initial target signal and the cross-file association characteristics of the signal logic; this application does not impose any limitations on this.

[0147] The pre-determination can be achieved in two ways: First, the electronic device parses the module information of the initial target signal. If all initial target signals belong to the same functional module, and the logic statements of that module are encapsulated in a single design file without any input / output port signals interacting with other files, then it is determined that only single-file tracing is required. If the initial target signal belongs to multiple different functional modules, or the input / output port signals of the module need to interact with other design files, then it is determined that cross-file tracing is required. Second, the electronic device pre-extracts port declaration information from all files in the subsystem design file set, constructs a port association graph between files, and then analyzes whether the logical link corresponding to the initial target signal involves port associations of different files in the graph. If the logical link does not cross any file boundaries and is limited to within a single file, then it is determined that single-file tracing is required. If the logical link needs to be connected through port signals from different files to form a cross-file link, then it is determined that cross-file tracing is required.

[0148] At this point, during cross-file tracing, the electronic device initializes the current signal set and global dependency libraries during the initialization phase. During the hierarchical recursive unrolling phase, as long as the current signal set is not empty, the electronic device repeatedly executes the following steps:

[0149] a. Round Start: Increment the iteration counter and create a temporary "new interface signal set" to collect all cross-module interface signals discovered in this round.

[0150] b. Parallel processing of all files: For each file in the design, call the aforementioned single-file signal dependency tracing algorithm, taking the "current signal set" and the file as input; merge the relevant statements within the submodule returned by the single-file signal dependency tracing algorithm into the "global dependency library"; from these relevant statements, filter out signals declared as input or output types in the file. It should be understood that these signals are the "bridges" for communication between the module and the outside world. Add these filtered interface signals to the "new interface signal set".

[0151] c. Update the starting point of the tracking: Perform a deduplication operation on the "new interface signal set", and use the result as the "current signal set" for the next iteration.

[0152] After completing the above iterative process, the top-level module integration phase begins. Specifically, when the electronic device finishes the recursive loop (i.e., no more new interface signals are found), it means that all file-level dependencies linked through interfaces have been clarified. At this point, the electronic device calls the single-file signal dependency tracing algorithm on the top-level file. The input to this call is all the signals accumulated in the "global dependency library," which represent key internal and interface signals from each file. Based on this process, the complex dependencies at the lower levels can be mapped or linked to the input and output ports of the top-level file, thereby clarifying how external stimuli affect internal target points.

[0153] Finally, the results obtained from tracing the top-level files are also merged into the "global dependency library", ultimately resulting in a set of global dependency statements containing complete causal paths across files.

[0154] S202, input the global dependency statement set into the code structure reconstruction module, remove irrelevant code from the global dependency statement set and complete the syntax, and obtain the filtered design.

[0155] The filtered design is a design document that contains only the causal relationship logic of the initial target signal.

[0156] It should be understood that the output of the signal tracing module is a set of statements containing key causal logic, but these statements are fragmented code pieces detached from their original context. They may come from different always blocks, be scattered across multiple files, and lack the keywords and structures (such as always, begin / end, case / endcase, etc.) necessary for them to be valid Verilog constructs. Directly inputting such fragments into a Large Language Model (LLM) will severely hinder the model's accurate understanding of circuit structure, control flow, and data flow, making it impossible to accurately generate stimulus sequences that meet the activation requirements of uncovered points.

[0157] Therefore, this application introduces a code structure reconstruction module. Its core task is to remove irrelevant code and complete the syntax of the global dependency statement set, reassembling disordered code fragments into syntactically complete, structurally sound, and semantically focused Verilog code blocks, i.e., a filtered DUT. Irrelevant code refers to redundant statements mixed into the global dependency statement set that have no direct or indirect causal relationship with the initial target signal, or statements that are merely format placeholders without actual logical meaning. Syntax completion supplements the missing keywords, structural identifiers, and code frameworks necessary for constructing valid Verilog syntax, such as completing the always / initial procedure block keywords, begin / end statement block delimiters, case / endcase conditional branch closures, module port declarations, etc., while restoring the logical hierarchy and execution order between statements, allowing scattered statements to form standardized and parsable Verilog code.

[0158] In this embodiment, the electronic device first classifies the relevant statements in the global dependency statement set according to grammatical features to obtain at least one set of relevant statements; for each set of relevant statements, the template with the highest adaptability is selected from the preset template library as the target template; the target template is filled based on the relevant statements, and the filled target templates are integrated to obtain the filtered design.

[0159] Specifically, syntactic features include at least one of the following: keywords, assignment types, and structural information of the original file. Keywords refer to Verilog syntax keywords contained in the relevant statements, such as assign, always, case, if, for, etc.; assignment types refer to the signal assignment methods of the statements, including continuous assignment, procedural assignment, conditional assignment, etc.; and structural information of the original file refers to information such as the code block type, module level, and logical link location to which the relevant statements belong in the original design file, such as belonging to a combinational logic always block, a sequential logic always block, or a case branch statement block, etc.

[0160] Specifically, the preset template library includes at least one of the following: continuous assignment template, conditional branch template, selection statement template, procedure block template, and generation block template. In this embodiment, the preset template library contains the above five types of templates. This template library is a standardized code framework collection built based on the standard syntax specifications of the Verilog language and commonly used logical structures designed at the register-transfer level. Each template contains complete Verilog syntax keywords, structure delimiters, and placeholder areas for fillable logic. It retains only the basic syntax framework and can be flexibly filled according to the logical content of the actual related statements to adapt to the structural reconstruction needs of different types of related statements.

[0161] More specifically, the continuous assignment template is a standardized framework based on the assign keyword, providing the basic format assign[LHS]=[RHS]; which is used to reorganize fragmented combinational logic assignment pieces. By filling the left and right value expressions in the fragments into the corresponding positions, a valid statement can be generated. For multi-drive scenarios of the same signal, multiple assign statements can be generated or integrated into a conditional assignment structure.

[0162] More specifically, the conditional branch template is a standardized conditional judgment code framework built on the if / else and if / elseif keywords. It is used to reconstruct incomplete conditional judgments and branch execution mechanisms. It includes a placeholder area for conditional expressions, an execution area for branch statements, and begin / end delimiters. It adapts to the reconstruction of logical statements with conditional judgments and can complete multiple branch conditions and corresponding execution logic according to actual needs. When the collected fragments contain conditional expressions (such as enable==1'b1) and their associated assignment statements, the template will reconstruct a complete if([condition])begin...endelsebegin...end or if-elseif chain. The template is responsible for completing the begin and end keywords and classifying the corresponding conditional fragments and statement fragments into the correct branch blocks.

[0163] More specifically, the selection statement template is a standardized branch selection code framework built on the `case`, `casez`, and `casex` keywords. It aggregates scattered branch logic belonging to the same selector, including a selection signal placeholder area, a branch matching value area, a branch execution statement area, and `case` / `endcase` closures. It adapts to the reconstruction of logic statements for multi-branch selections and supports branch matching for both fixed-width and variable-width signals. When multiple branch assignment fragments sharing the same selection signal (such as `state`) are identified, the template reconstructs the `case([select_signal])...endcase` structure, creating a `[value]:begin...end` block for each unique branch value (`[value]`) and filling in the corresponding execution statement fragment. Simultaneously, the template ensures the inclusion of a `default` branch (which can be empty) to guarantee syntactic integrity.

[0164] More specifically, the procedure block template is a standardized procedure assignment code framework built on the always / initial keywords. It is used to reconstruct a complete procedure block encapsulation for sequential or combinational logic blocks. It includes a sensitive list placeholder area, a procedure statement execution area, and is divided into combinational logic (@ There are two sub - templates for sequential logic (@posedge / @negedge), which are adapted to reconstruct the procedural assignment statements of register - type signals. Specific sensitive signals and internal execution logic can be filled in. The corresponding processing logic is as follows: According to the characteristics of the statements in the fragments (such as whether it contains non - blocking assignment <= to judge as sequential logic, whether it contains blocking assignment = and has no timing control to judge as combinational logic), select the appropriate always template. For sequential logic, the format is always@(posedge[clk]ornegedge[rst_n])begin...end. The template infers the clock and reset signals from the fragment - associated signals or extracts them from the design context, fills them into the sensitivity list, and places the relevant non - blocking assignment statements inside the begin - end block. For combinational logic, the format is always@( )begin...end. The template integrates all relevant blocking assignment or if / case statement fragments into this block.

[0165] More specifically, the generate - block template is a standardized code - generation framework built based on the generate / endgenerate keywords, which is used to handle the structured code - generation logic dependent on parameters or loops. It contains generation - logic placeholder areas such as for loops and if - condition judgments, adapts to the reconstruction of logic statements with parameterization and loop generation, and supports dynamically generating repeated logic structures according to module parameters. The corresponding processing logic is as follows: When the traced fragments involve parameterized instantiation or loop - generation statements (such as for(genvari = 0;i<WIDTH;i = i + 1)), this template is used. The template reconstructs the generate...endgenerate shell and retains the internal if - generate, case - generate, or for - generate structural skeletons, and fills the instantiation statements related to the target signals or the logic inside the loop body into the corresponding positions.

[0166] In this embodiment, for the global dependency statement set obtained from the signal tracing module, the electronic device first traverses all relevant statements in the global dependency statement set, extracts the complete syntax features of each statement and performs feature marking; then, based on the feature marking, clusters and groups all relevant statements. The relevant statements that contain the same core keywords, belong to the same assignment type, and have the same original file structure information are grouped into one group. If a statement has multiple syntax - feature intersections, its belonging group is determined according to the main syntax feature corresponding to its core logic. Finally, multiple groups of relevant statements with consistent features are obtained, and each group of statements is a Verilog logic statement of the same type, adapting to the reconstruction requirements of the same type of template.

[0167] Furthermore, for each set of related statements, the electronic device compares the grammatical features corresponding to each set of related statements with the grammatical matching features of each template in the preset template library, and calculates the feature matching degree; the template with the highest feature matching degree is determined as the target template.

[0168] Specifically, the electronic device first extracts the syntax matching features of each template in the preset template library, namely the core keywords, assignment types, structural information, etc. of each template, which are the inherent matching attributes of the template. Then, it compares the syntax features of each group of related statements with the syntax matching features of each template item by item: for keyword features, it counts the number of overlaps between the core keywords of the statements in the group and the keywords in the template syntax matching features; for assignment type features, if the assignment type of the statements in the group is consistent with the assignment type adapted by the template, it is recorded as a match, otherwise it is recorded as a mismatch; for the structural information features of the original file, it counts the overlap dimension between the structural information of the statements in the group and the structural information adapted by the template.

[0169] The electronic device then calculates the feature matching degree based on preset weights. In this embodiment, the keyword feature has the highest weight, followed by the assignment type feature, and the original file structure information feature has the lowest weight. The calculation formula is: Feature matching degree = (Number of overlapping keywords / Total number of core keywords in the template) × Keyword weight + (Assignment type matching value) × Assignment type weight + (Structure information overlap dimension / Total dimension of template adapted structure information) × Structure information weight. Each weight value is a preset fixed proportion, and the sum of the weights is 1. After calculation, the matching degree value between each group of related statements and each template is obtained, and the template with the highest value is the one with the highest feature matching degree.

[0170] In practical applications, feature matching can be transformed into vector similarity matching by constructing grammatical feature vectors and template matching feature vectors. The feature matching degree can be represented by calculating cosine similarity, Euclidean distance, etc. Alternatively, a machine learning classification model can be used, taking the grammatical features of relevant sentences as input and the template type as output. The matching probability of each group of sentences with each template can be directly obtained through model training, and the template with the highest probability is determined as the template with the highest matching degree. This embodiment does not limit this.

[0171] In addition, in practical applications, related statements can be grouped according to their module affiliation and signal logic links in the original design file, and related statements in the same module and the same logic link can be grouped together; they can also be grouped according to the signal operation type of the statements (such as arithmetic operations, logical operations, bitwise operations), and this embodiment does not limit this.

[0172] Furthermore, it should be understood that the preset template library provided in this embodiment (containing five types of templates: assign, always, case, if-else, and generate) is an extensible and open collection. Those skilled in the art can add new templates to this library as needed to support other hardware description syntax structures (such as SystemVerilog-specific interfaces, clocking blocks, packages, etc.), or customize dedicated templates for specific company or project coding standards. New templates will not conflict with existing templates; they only need to adhere to the same interface specification of "input code fragments, output complete syntactic structure" to be integrated into the reconstruction process.

[0173] In this embodiment, the process of the electronic device filling target templates based on relevant statements and integrating the filled target templates consists of two steps: target template instantiation and filling, and template structure integration. The final result is a filtered design conforming to the Verilog standard syntax specification. The specific process is as follows:

[0174] 1. Target Template Instantiation and Filling: For each target template obtained by matching related statements, the electronic device first identifies the preset placeholders and logical filling areas in the template. Then, it extracts the corresponding actual signal names, logical expressions, conditional statements, execution statements, and other specific content from the logical content, syntactic features, and original design context information of the related statements in that group, and accurately replaces the placeholders in the template. For the logical filling area of ​​the template, the related statements in that group are arranged in the original logical association order and filled in completely. The template automatically completes the missing Verilog syntax keywords and structure delimiters, completing the instantiation and filling of a single target template, so that each filled target template forms a standardized Verilog code block with complete syntax and independent logic.

[0175] 2. Template Structured Integration: After the instantiation and filling of all target templates are completed, the electronic device performs unified structured integration on all the filled standardized code blocks. First, it extracts the input and output port signals related to the causal path of the initial target signal from all code blocks, and creates a top-level module shell based on these port signals. The module declaration only retains the aforementioned core port signals. Then, it places all the filled code blocks in an orderly manner within the top-level module shell according to the Verilog general design specification of combinational logic first and sequential logic second. Finally, it performs syntax verification on the integrated content to ensure that there are no syntax conflicts or structural omissions, and finally outputs one or more syntactically correct code files that can be parsed by a standard Verilog compiler. This code file is the filtered design.

[0176] It should be understood that the filtering design obtained based on the above process has the following core characteristics: syntactic integrity, that is, it conforms to the Verilog language specification, eliminating the syntactic errors and structural omissions of the original code fragments; semantic focus, that is, it strictly preserves all causal logic from the initial target signal to the top-level port, completely eliminating irrelevant modules, signals and statements in the original design, and the size is usually several orders of magnitude smaller than the original design; and structural standardization, that is, the code is presented in a standard, LLM-recognizable construction (such as a complete always block and case statement), which greatly reduces the ambiguity of model parsing.

[0177] In this embodiment, grouping related statements before template matching integrates scattered statements of the same type into a whole, avoiding repeated template matching operations on individual statements, significantly reducing the number of matching operations, improving the overall efficiency of code structure reconstruction, and ensuring that statements of the same logical type can be reconstructed uniformly based on the same template, avoiding inconsistencies in the reconstructed structures of statements of the same type. By comparing each feature item and calculating the feature matching degree, accurate quantitative matching between related statements and templates can be achieved. Compared with manual template selection, subjective judgment errors are effectively avoided, making the selection of target templates more in line with the actual syntactic features and logical requirements of the statements, ensuring the accuracy and standardization of subsequent code structure reconstruction, and ensuring that the filled template can form a syntactically complete and logically coherent Verilog code block.

[0178] As an example, Figure 3 An example diagram illustrating code structure reconstruction provided in this application embodiment, such as... Figure 3 As shown, the left side shows a case code fragment with missing closed structure and default branch. The electronic device automatically adds the default branch (green addition part) and completes the endcase keyword after matching and selecting the target statement template based on the preset Verilog code structure repair template library (i.e. the preset template library in the previous process) and the endcase keyword, forming a complete case(clk_div_cfg)...endcase selection statement block.

[0179] like Figure 3 As shown, the left side shows code fragments that lack the sensitive list in the header of the always procedure block and the begin / end delimiters. After the system matches the procedure block template, it automatically supplements the always@(posedgeclkornegedgerst_n) sensitive list (the green supplement part) and completes the begin and end structure delimiters, encapsulating the scattered conditional assignment statements into a complete sequential logic procedure block.

[0180] Throughout the repair process, the template automatically identifies the syntactic features and missing parts of the code fragments. By supplementing necessary syntactic keywords, structure delimiters, and logical branches, it reconstructs the originally fragmented code into a complete logical block that conforms to the Verilog specification, while preserving the core functional logic of the original code. The final output is standard code that can be directly parsed by the Verilog compiler.

[0181] It should be understood that in practical applications, grouping can be omitted, and grammatical features can be extracted directly for each relevant statement. The grammatical features of each statement can be compared one by one with the grammatical matching features of each template in the preset template library, and the feature matching degree can be calculated. The appropriate target template can be matched and reconstructed separately for each statement. This application does not limit this.

[0182] S203, input the filtered design and initial target signal set into the excitation generation module to obtain the excitation sequence for the uncovered points.

[0183] In this embodiment, the stimulus generation module uses a large model to output the stimulus sequence. Specifically, the filtered design and initial target signal set obtained from the aforementioned process are input into the stimulus generation module, which automatically generates a highly targeted test stimulus sequence through the reasoning capability of the large language model.

[0184] It should be understood that the filtered design is a minimal set of syntactically complete code that maintains a causal relationship between the retained and uncovered points. Its purpose is to provide the model with the precise context needed to understand the deep logical paths, rather than for actual simulation. At the same time, the electronic device explicitly tells the model the verification task to be solved, namely one or more specific uncovered points, such as a line of code that has never been executed, a signal bit that has not been toggled, or a state machine state that has not been entered.

[0185] Specifically, in this embodiment, the electronic device first constructs a structured task instruction package based on the filtered design, the initial target signal set, and preset verification engineering constraints. The structured task instruction package includes core tasks such as model role localization and stimulus sequence generation, standardized technical constraints, and contextual information related to the filtered design.

[0186] Subsequently, the electronic device, based on the structured task instruction package, repeatedly executes the following process until the coverage reaches a preset threshold and / or the number of iterations reaches a preset number, at which point the iteration stops and an excitation sequence is obtained: the structured task instruction package is sent to the large language model to generate an initial excitation sequence for the uncovered points corresponding to the initial target signal set;

[0187] The initial stimulus sequence is integrated into the subsystem-level test environment. Compilation and simulation verification are completed based on the original design code corresponding to the subsystem design file set, and the current verification coverage is collected synchronously. If an error is detected in the initial stimulus sequence during the verification process, the diagnostic information corresponding to the error is captured and fed back to the large language model to obtain the cause of the defect. Based on the cause of the defect, the initial stimulus sequence is repaired, optimized or regenerated, and the corrected stimulus sequence is used as the new initial stimulus sequence. If the initial stimulus sequence is found to be error-free and the compilation and simulation verification are completed, the verification coverage is updated based on the original design code, and the iteration count is updated synchronously.

[0188] In this embodiment, errors mainly fall into two categories: compilation errors and runtime errors. Compilation errors refer to those where the initial stimulus sequence does not conform to Verilog syntax specifications, port definitions do not match the original design code, or signal bit widths are inconsistent, causing the compiler to fail to compile. Runtime errors refer to those where the stimulus sequence can be compiled but occur during simulation, including illegal signal value inversions, state machine entering infinite loops, abnormal signal interaction between modules, and reset logic not taking effect, all of which affect the normal execution of the simulation. Diagnostic information is a comprehensive set of information used to locate the causes of defects in the stimulus sequence, specifically including error messages output by the compiler, error logs generated by the simulator, signal waveform context collected during the simulation, timing information of the stimulus sequence execution phase, and signal interaction data of the module ports.

[0189] The preset threshold is a coverage target value pre-set based on the engineering requirements of subsystem-level RTL verification. Its specific value can be flexibly configured according to different verification stages. For example, the preset threshold for module-level verification is 90%, and the preset threshold for subsystem-level integration verification is 95%. It can be the overall code coverage, or a specific coverage such as branch coverage or state machine coverage. The preset iteration number is the maximum iteration limit for generating large model stimuli pre-set based on verification efficiency and engineering cost. It is determined by technical personnel based on the subsystem complexity, the number of uncovered points, and the efficiency of large model stimuli generation, in order to avoid the problem of excessively long verification cycles caused by unlimited iteration.

[0190] More specifically, when constructing a structured task instruction package, the electronic device integrates multi-dimensional information according to a standardized instruction framework. First, it clarifies the model's role, positioning the large language model as a subsystem-level RTL verification engineer, limiting its professional perspective and technical boundaries for stimulus generation. Second, it clarifies the core task of stimulus sequence generation, accurately describing the information of uncovered points to be activated, the activation conditions of the initial target signal, and the core verification objectives to be achieved by the stimulus. Third, it incorporates standardized technical constraints, including the subsystem's clock frequency, reset type, valid value range of port signals, register configuration rules, and legal jump paths of the state machine, among other practical engineering constraints. Finally, it integrates filtered design context information, structurally encapsulating the complete code of the filtered design, the core causal logic chain, the top-level port definition, and the position of the initial target signal in the logic chain. At the same time, it adds stimulus format requirements, clarifying that the output format of the stimulus sequence is Verilog code or standardized test vectors that can be directly integrated into the test environment.

[0191] After receiving the structured task instruction package, the electronic device initiates a closed-loop iterative process of large model generation, simulation verification, and feedback optimization, as follows:

[0192] 1. For the first time, the complete structured task instruction package is distributed to the large language model, which then generates an initial stimulus sequence for the uncovered points based on the filtered causal logic and task requirements.

[0193] 2. The initial stimulus sequence is automatically integrated into the already built subsystem-level test environment, and the simulation tool is called to complete the compilation based on the original design code. If a compilation error occurs, the diagnostic information is directly captured and fed back to the model.

[0194] 3. After successful compilation, perform simulation verification, synchronously collect coverage data and signal waveforms, and capture diagnostic information and feed it back to the model if runtime errors occur;

[0195] 4. The large model performs defect cause analysis based on the feedback diagnostic information. For simple problems such as syntax errors and port mismatches, the stimulus sequence is directly repaired. For complex problems such as logic insufficiency and inability to activate uncovered points, the stimulus logic is re-optimized and a new stimulus sequence is generated.

[0196] 5. Use the corrected stimulus sequence as the new initial stimulus sequence, and repeat the above compilation, simulation, and feedback steps to update the verification coverage and iteration count synchronously.

[0197] 6. When the coverage rate reaches the preset threshold and / or the number of iterations reaches the preset number of iterations, the iteration process is terminated immediately, and the stimulus sequence with the best current verification effect is output as the final result.

[0198] In practical applications, errors can also include simulation timeouts caused by stimulus sequences, no coverage improvement, and conflicts with hardware physical characteristics. Diagnostic information can also include simulation resource usage data, coverage increment logs, and signal propagation data within modules. The preset threshold can also be set with differentiated target values ​​based on the importance of uncovered points. The preset number of iterations can also be dynamically adjusted, flexibly increasing or decreasing according to the coverage increment of each iteration. Iteration termination conditions can also include coverage increment in a single iteration being lower than a preset minimum value, the generated stimulus sequence being highly repetitive with historical sequences, and manual determination that no further iteration is needed. The structured task instruction package can also be constructed through templated configuration, migration of historical stimulus cases, and manual supplementation of professional annotations, etc., but this embodiment does not limit this.

[0199] Furthermore, in practical applications, based on the filtering-guided large language model to generate incentives, a reinforcement learning mechanism can be introduced to iteratively optimize the generated sequences. Specifically, the increase in coverage can be used as a reward signal to guide the model to adaptively fine-tune key parameters in the incentive sequence (such as transaction interval, data value, state transition order, timing of triggering, etc.) to explore a better incentive space and further improve the activation efficiency of uncovered points. At the same time, the incentive generation framework of this embodiment is not limited to generating UVM test sequences, but can also be extended to automatically generate auxiliary files required for the verification process, such as assertions (SVA), functional coverage models, or verification plan documents, to achieve automated assistance for different stages of the verification task and improve the full-process automation level of subsystem-level RTL verification. This embodiment does not limit this.

[0200] In this embodiment, a structured task instruction package is constructed and a closed-loop iterative process is executed. On the one hand, by standardizing and structuring the instructions, the scattered design information, verification tasks, and engineering constraints are integrated into an input that the large model can accurately parse, effectively avoiding the ambiguity of natural language instructions and improving the targeting and accuracy of large model stimulation. On the other hand, through the closed-loop iteration of stimulation-simulation-feedback, the stimulation sequence is automatically optimized, allowing the model to continuously correct the stimulation logic based on actual simulation results. This effectively solves the logical loopholes that may exist in a single stimulation and improves the success rate of activating uncovered points in the stimulation sequence. At the same time, by setting a preset threshold for coverage and an upper limit for the number of iterations, the verification effect is guaranteed while the verification efficiency is taken into account, ineffective iterations are avoided, the cost of manual intervention is effectively reduced, and the intelligent and automated generation of stimulation sequences is realized.

[0201] In addition, in practical applications, the filtered design, the initial target signal set and the verification task described in natural language can be directly input into the large language model to generate the excitation sequence; at the same time, the excitation sequence can also be generated through traditional script writing, manual writing, random excitation combined with constraints, etc., and this application does not limit the specific methods used.

[0202] As a preferred design, during the analysis of the filtered design and the attempt to generate stimuli, the large language model is simultaneously required to perform coverage reachability analysis. Specifically, the large language model combines the causal relationship logic of the filtered design with the information on uncovered points corresponding to the initial target signal set to infer whether uncovered points can be activated by legitimate stimuli. If it is inferred that uncovered points cannot be activated by legitimate stimuli due to design limitations, exemption suggestions are generated. Exemption suggestions are presented in the form of structured annotations, clearly indicating the reasons for exemption and the corresponding design logic basis. Based on each exemption suggestion, an exemption report is generated and marked in the coverage database for use in the subsequent collection and updating of coverage to exclude reasonably exempted uncovered points.

[0203] Among them, being able to be activated by legitimate incentives means that the uncovered point can be activated by applying effective test incentives, provided that it complies with the subsystem hardware design logic, port constraints, register configuration rules, and legal state machine transition relationships. Conversely, typical scenarios where the point cannot be activated by legitimate incentives due to design limitations include: core signals being fixed to fixed values ​​by hardware logic and unable to be flipped; the target state of the state machine being permanently unreachable due to multiple mutual exclusion conditions; related functional logic being permanently disabled in the actual application configuration of the chip; incorrect interface signal connections between modules leading to broken logic links; and register read / write permissions being fixed by hardware, causing the configuration to fail.

[0204] More specifically, when the large language model performs coverage reachability analysis, it first identifies all signal propagation paths, condition judgment nodes, and state transition relationships from the initial target signal to the uncovered point based on the complete causal logic chain after filtering. Then, it analyzes each path to determine if there are any hard constraints at the design level and verifies whether there are legitimate signal combinations and timing logic that satisfy the activation conditions of the uncovered point. If the analysis determines that all paths have design constraints and no legitimate incentive method can activate the uncovered point, then the uncovered point is determined to be an unreachable coverage point, and a corresponding exemption suggestion is generated. In this embodiment, when generating the exemption suggestion, the location, identification information, and specific exemption reasons of the uncovered point are clearly recorded in the form of structured comments, along with the corresponding design logic basis, including the relevant key lines of code, signal constraints, hardware design rules, etc.

[0205] Furthermore, the electronic device collects exemption suggestions for all uncovered points, integrates them into an exemption report according to a standardized report format, and includes subsystem identifier, verification stage, list of exempted uncovered points, reasons and logical basis for exemption for each point, coverage exemption calculation, etc. Then, the key information of the exemption report is synchronized to the coverage database, and a unique exemption identifier and associated report link are added to each exempted uncovered point.

[0206] In practical applications, scenarios where the design itself limits the activation of legitimate incentives may include situations where fixed parameter configurations in parametric design render some logic invalid, or timing constraints in asynchronous signal interactions prevent the logic from being triggered stably. Exemption suggestions may also be presented in the form of independent text files, tables, database records, etc., but this embodiment does not limit this.

[0207] In this embodiment, generating an exemption report and marking it in the coverage database can accurately identify unreachable uncovered points caused by design flaws, reasonably excluding them from coverage statistics, avoiding technical personnel wasting a lot of time and effort on invalid uncovered points, and effectively improving verification efficiency. At the same time, the exemption report provides a scientific and rigorous basis for the coverage statistics, allowing the verification coverage to truly reflect the actual verifiability of the subsystem and avoiding misjudgments caused by falsely low coverage. In addition, the exemption reasons and design logic basis clearly stated in the exemption report can also provide accurate problem location for subsequent design optimization, helping R&D personnel to discover problems such as logical redundancy and unreasonable hardware constraints in the design, thus having the dual value of improving verification efficiency and guiding design optimization.

[0208] As a preferred example, when generating an exemption report based on exemption recommendations, the electronic device collects each exemption recommendation to generate an exemption candidate point report and submits the exemption candidate point report to the manual review stage; if the exemption candidate point is confirmed as a reasonable exemption by manual review, the exemption candidate point is marked in the coverage database by an automated script.

[0209] Correspondingly, if the manual review determines that the exemption candidate point is unreasonable, the review opinion will be fed back to the large language model, which will then optimize the incentive sequence generation logic based on the review opinion and continue to execute the incentive sequence generation and iteration process.

[0210] Specifically, the electronic device first integrates all exemption suggestions generated by the large model in a structured manner to generate an exemption candidate point report. The report clearly lists the identifiers, locations, exemption reasons and logical basis of all candidate exemption points, and includes the relevant core code and logic link diagrams of the filtered design.

[0211] Subsequently, the electronic device pushes the report to the verification engineer's manual review platform. Professional engineers, based on the subsystem's design requirements, hardware implementation principles, and actual application scenarios, verify and judge each candidate exemption point. If the manual review confirms that a candidate exemption point cannot be activated due to design limitations, and it is deemed a reasonable exemption, an automated script is triggered to write the candidate point's identifier, exemption type, review comments, and other information into the coverage database, completing the exemption marking. This point will be automatically excluded during subsequent coverage statistics. If the manual review determines that a candidate exemption point is activatable, and the large model's exemption inference contains errors, the manual review comments are accurately fed back to the large language model. These comments include the activation basis for uncovered points, the direction of the activation logic to be adjusted, and any missing design constraints. Based on these comments, the large model re-analyzes the filtered causal logic, optimizes the activation strategy, and continues the generation, simulation, and iteration process of the stimulus sequence until the uncovered point is activated or a new accessibility analysis is completed and a new exemption suggestion is generated.

[0212] In this embodiment, submitting the exemption candidate point report to the manual review stage and introducing the manual judgment of professional engineers can effectively compensate for the limitations of large models in terms of design background understanding and hardware physical characteristic analysis. This avoids the wrong exemption of reasonable uncovered points due to model inference errors, ensuring the accuracy and rigor of exemption judgment and making the exemption marks in the coverage database more credible in engineering. At the same time, the feedback mechanism of manual review opinions can provide precise guidance for the large model's activation logic, promote the continuous optimization of the model's activation strategy, improve the large model's activation capability and the accuracy of accessibility analysis, and form a positive cycle of model inference-manual review-model optimization, further improving the reliability and effectiveness of the entire verification process.

[0213] S204, performs subsystem-level register transfer level verification based on the stimulus sequence.

[0214] In this embodiment, the electronic device is pre-integrated with a standardized subsystem-level RTL verification platform. This platform includes an original design code parsing module, a test environment integration module, a simulation execution module, a coverage acquisition module, and a result analysis module, which can realize the automatic integration, compilation, simulation, and coverage statistics of stimulus sequences.

[0215] Based on the aforementioned subsystem-level RTL verification platform, the electronic device will automatically integrate the final stimulus sequence obtained from the aforementioned process into the test environment of the verification platform, completing the signal interface and timing logic adaptation between the stimulus sequence and the test platform. Subsequently, the compilation module of the verification platform is called to jointly compile the stimulus sequence and the original design code based on the original design code of the subsystem design file set, generating an executable simulation file. Then, the simulation execution module is started to execute the simulation according to the actual working timing of the subsystem, synchronously collecting waveform data of all port signals and internal node signals during the simulation process, and recording the simulation log.

[0216] Furthermore, the coverage acquisition module extracts multi-dimensional coverage data such as code coverage, branch coverage, and state machine coverage from the simulation results, compares it with preset thresholds and exemption flags in the coverage database, and generates a coverage statistical report. Then, the result analysis module performs a comprehensive analysis of the simulation waveforms, coverage reports, and simulation logs, and outputs the verification results, including the activation status of uncovered points, the execution effect of stimulus sequences, and potential logical problems in the design. If the verification results reach the preset coverage target, the subsystem-level RTL verification is completed. If there are still uncovered points that are not activated and are not exempted, these uncovered points are used as new verification targets, and the process returns to S201 to re-execute the subsequent steps until all verification tasks are completed.

[0217] The method provided in this embodiment can accurately filter initial target signals by using uncovered point information as the core guide. Through a collaborative mechanism of single-file signal dependency tracing and cross-file recursive dependency tracing, it can completely extract the core logical statements that have causal relationships with the initial target signals within a single file and across files, forming a set of global dependency statements without redundancy. Then, the code structure reconstruction module removes irrelevant code fragments and completes the syntax, ultimately generating a filtered design that is syntactically complete, structurally sound, and focuses only on the core causal logic of uncovered points. This fundamentally solves the technical problems in traditional subsystem-level RTL verification, such as the lack of accurate logical basis for stimulus generation, easy omissions in cross-file logic tracing, and redundant code interfering with model parsing. It ensures that uncovered points... The accuracy and completeness of core logic tracing perfectly match the modular design features of subsystems. Furthermore, the standardized and automated process design replaces the tedious manual analysis and screening of core code, effectively reducing labor costs and subjective errors, and improving the overall efficiency of subsystem-level RTL verification. More importantly, the method in this embodiment provides a high-quality and highly focused input foundation for the subsequent generation of targeted stimulus sequences for large language models, enabling the model to accurately parse the logical activation conditions of uncovered points, achieve efficient generation of accurate stimulus sequences, and build a technical closed loop of "accurate tracing - standardized reconstruction - intelligent stimulus generation". This effectively improves the intelligent and engineering adaptability of subsystem-level RTL verification and effectively increases the activation efficiency and verification coverage of uncovered points.

[0218] As further explanation, Figure 4 A flowchart illustrating a subsystem-level stimulus sequence verification method provided in this application embodiment. Figure 2 This embodiment, based on the aforementioned embodiments, further defines the process by which the stimulus generation module generates the stimulus sequence. For example... Figure 4 As shown, the method in this embodiment includes:

[0219] S401 calls at least two heterogeneous large language models in parallel, and obtains corresponding candidate excitation sequences based on the filtered design and the initial target signal set, respectively.

[0220] S402, Determine the excitation sequence based on each candidate excitation sequence.

[0221] In this embodiment, to ensure the quality and diversity of generated stimuli and avoid the cognitive limitations of a single model, the electronic device employs a multi-model collaborative generation strategy. Specifically, the electronic device uses the stimulus generation module to call multiple heterogeneous large language model instances in parallel, such as large language models trained on different architectures. Each model instance independently receives the same filtered design and structured task instruction package, and based on its own knowledge and reasoning patterns, generates what it considers the optimal test sequence scheme as a candidate stimulus sequence through the aforementioned iterative process.

[0222] Furthermore, the electronic device selects the candidate activation sequence with the highest coverage from the output of each large language model as the final activation sequence.

[0223] In practical applications, it is not necessary to use the one with the highest coverage as the final stimulus sequence. A comprehensive evaluation can be conducted by combining multiple dimensions such as simulation efficiency, stimulus length, logical complexity, and engineering maintainability of the stimulus sequence. For example, the sequence with the highest coverage, shortest stimulus length, and least simulation time can be selected as the final stimulus. Alternatively, multiple candidate stimulus sequences can be logically fused to extract the core effective stimulus segments of each sequence and integrate them into a better composite stimulus sequence. The stimulus sequence that best meets the engineering requirements can also be selected through manual review, combined with the professional experience of the verification engineer. This embodiment does not impose any restrictions on this.

[0224] The method provided in this embodiment, by calling at least two heterogeneous large language models in parallel, can fully leverage the differentiated technical advantages of different models in circuit logic parsing, stimulus scene construction, code generation optimization, etc., to achieve diverse output of stimulus sequence schemes for activation needs of uncovered points. This not only effectively avoids the generation limitations of a single model and enriches the scene coverage dimension and logic adaptation form of candidate stimulus sequences, but also shortens the overall generation time of stimulus sequences through parallel operation of multiple models, effectively improving the generation efficiency and diversity of stimulus sequences, and laying a rich candidate foundation for subsequent selection of accurate and efficient optimal stimulus sequences.

[0225] As a comprehensive description of the verification method for the subsystem-level excitation sequence of this application, Figure 5 A schematic diagram illustrating the principle of a subsystem-level excitation sequence verification method provided in this application embodiment is shown below. Figure 5 As shown, in the input phase, the electronic device receives two core inputs: the subsystem design document and the initial target signal corresponding to the uncovered point information. In the signal dependency tracing phase, the electronic device uses a signal dependency tracker to filter out the initial target signal, guided by the uncovered points. Through single-file signal dependency tracing and cross-file recursive dependency tracing, it extracts logical statements that have a direct or indirect causal relationship with the initial target signal, forming a global dependency statement set. In the code structure reconstruction phase, the electronic device uses a Verilog code structure repair template library to perform syntax completion, structural integration, and irrelevant code removal on the scattered code fragments in the global dependency statement set, generating a filtered design that retains only the core causal logic of the uncovered points.

[0226] Subsequently, the multi-model collaborative stimulus generation stage begins. The electronic device inputs the filtered design and structured task instruction package into an LLM model pool containing multiple heterogeneous large language models. At this point, each model infers independently in parallel, generating candidate stimulus sequences containing stimulus sequences and corresponding activation paths. When a stimulus sequence generated by a certain model fails in subsequent simulations, the simulation failure diagnostic information will trigger the regeneration data stream of that model, driving the model to repair and optimize the stimulus sequence.

[0227] Through the above stages, multiple candidate stimulus sequences can be obtained. The electronic device integrates these candidate stimulus sequences into the UVM simulator and completes compilation and simulation verification based on the original design file. During the simulation verification process, coverage data and simulation logs are collected simultaneously. The stimulus sequence with the best coverage effect is selected through a multi-model complementarity mechanism, while sequences with logical defects are eliminated.

[0228] Finally, the electronic device outputs a verification report containing information such as verification coverage, execution effect of stimulus sequence, and activation status of uncovered points, completing the subsystem-level register transfer level verification process.

[0229] As described above, the method in this application constructs a self-closing-loop automated analysis and generation system from coverage gaps to targeted incentives. It abandons the heavy-duty global design analysis methods and the simple incentive generation mode of inputting design code or fragmented data into the model in known technologies. Through a lightweight cross-file signal dependency tracing algorithm, it accurately extracts the complete cross-file causal logic chain from uncovered points to the top-level controllable port. Then, through code structure reconstruction based on normalized templates, it generates a syntactically complete and semantically highly focused filtered design, providing minimal and accurate structured context for large language models. Simultaneously, it combines parallel inference of multiple heterogeneous large language models with a real-time feedback engine integrated into the simulation process, forming... The automated quality enhancement closed loop of generation-simulation-feedback-regeneration not only effectively avoids the cognitive limitations of a single model and solves the problem of model parsing ambiguity caused by fragmented code, but also improves the pertinence, robustness, and engineering practicality of the stimulus sequence. Furthermore, it achieves full-process automation from uncovered point identification, signal dependency tracing, code structure reconstruction to stimulus generation and simulation verification. This replaces the tedious manual analysis of logic and stimulus writing in traditional verification, effectively reducing labor costs and subjective errors, accurately improving the activation efficiency of uncovered points and the overall coverage of subsystem-level RTL verification, while also effectively improving the intelligence and engineering adaptability of the verification process.

[0230] As a demonstration of the beneficial effects of this application, its effectiveness has been verified and evaluated on real industrial-grade subsystem designs covering various on-chip interconnect protocols such as APB, AHB, AXI, P-Channel, and Q-Channel. Details of the baseline designs are shown in Table 1. These designs range from 3 to 10 modules and have code sizes ranging from 800 to over 3000 lines, representing the engineering challenges in real subsystem-level register transfer level verification scenarios.

[0231] Table 1. Baseline Design Details

[0232]

[0233] As shown in Table 1, the baseline design selected for this evaluation covers various hardware modules with multiple on-chip interfaces, including an APB-based watchdog and power control unit, an AHB CORDIC accelerator, Q-channel and P-channel low-power controllers, and an AXI-based interface remapping module. Figure 6 Example diagrams comparing the effects of a subsystem-level stimulus sequence verification method provided in this application embodiment are shown. Figure 6 As shown, this application selects two representative traditional baseline methods in the industry for comparative testing: The first method directly uses the original design as input, directly inputting the unprocessed complete subsystem-level RTL code into a large language model. Because the original design contains a large number of modules and signals unrelated to the verification objective, the effective information is overwhelmed by redundant information, and the model has difficulty identifying the core logic, ultimately achieving an average coverage improvement of only 3.35%. The second method is a black-box optimization method based on machine learning, represented by Google Vizier. This method does not rely on code semantic understanding, but only parameterizes the stimulus generation and iteratively searches in the parameter space through an algorithm. It suffers from high computational cost and bottlenecks in optimization effect, ultimately achieving an average coverage improvement of only 6.66%.

[0234] The method implemented in this application, through "signal tracing-code reconstruction" to generate filtering and guide the large model in generating stimulus sequences, ultimately achieves an average coverage improvement of 11.53%, far exceeding the two baseline methods. This method accurately extracts the smallest subset of causal logic strongly correlated with uncovered points, providing a precise and non-redundant structured context for the large language model. This allows the model to escape interference from irrelevant code and focus on generating targeted stimulus sequences from core logic, thereby achieving a higher coverage improvement and faster coverage convergence speed. Essentially, it significantly improves the efficiency of stimulus sequence generation and the actual effectiveness of subsystem-level verification.

[0235] Furthermore, this application constructs a mechanism for parallel generation and optimal integration of multiple heterogeneous large language models. The same filtered design (FilteredDUT) and structured task instruction package are distributed in parallel to three types of heterogeneous large language models (GPT-4.1, Claude4.5, and Gemini2.5Pro). Each model independently generates stimulus sequences based on its own parameter system and inference mode. Finally, the sequence with the best coverage improvement is selected as the final stimulus sequence. Test results show that the final coverage of different models on six benchmark designs is highly similar with minimal differences. For example, in the Watchdog design, the final coverage of the three models is 98.70%, 98.70%, and 98.84%, respectively. In the more complex Busremap design, the final coverage of the three models is 95.40%, 95.66%, and 95.60%, respectively.

[0236] The test results above demonstrate that the core performance of this application does not stem from the "black box" capabilities of a specific large language model, but rather from the precise and structured context generated by the "signal tracing-code reconstruction" process. This context, as a general, model-agnostic design intent blueprint, effectively guides large language models with different architectures to perform correct logical reasoning. Therefore, the verification system of this application is insensitive to the choice of the underlying model, possesses excellent robustness and technology stack flexibility, and fundamentally reduces the engineering risks and uncertainties caused by reliance on a single model vendor, model version iteration, or service changes.

[0237] The above embodiments describe a method for verifying a subsystem-level stimulus sequence from the perspective of the process flow. The following embodiments describe a device for verifying a subsystem-level stimulus sequence from the perspective of a virtual module or virtual unit. For details, please refer to the following embodiments.

[0238] This application provides a subsystem-level excitation sequence verification device. Figure 7 This is a schematic diagram of the structure of a subsystem-level excitation sequence verification device provided in an embodiment of this application, as shown below. Figure 7 As shown, the device includes:

[0239] The tracing module 71 is used to input the initial target signal set and the subsystem design file set into the signal tracing module, and obtain the global dependency statement set through single-file signal dependency tracing or cross-file recursive dependency tracing; wherein, the initial target signal is obtained based on the information of the uncovered points;

[0240] Reconstruction module 72 is used to input the global dependency statement set into the code structure reconstruction module, remove irrelevant code from the global dependency statement set and complete the syntax, and obtain the filtered design; the filtered design is a design file that only contains the causal relationship logic of the initial target signal.

[0241] Generation module 73 is used to input the filtered design and initial target signal set into the excitation generation module to obtain the excitation sequence for the uncovered points;

[0242] Verification module 74 is used to perform subsystem-level register transfer level verification based on the stimulus sequence.

[0243] In another possible implementation of this application embodiment, the traceability module 71 is specifically used for:

[0244] For each initial target signal in the initial target signal set, perform signal dependency reverse tracing based on each file in the subsystem design file set, extract relevant statements in each file that have a logical causal relationship with the initial target signal, and use them as the single file tracing results for each file.

[0245] The single-file tracing results corresponding to each file are summarized and merged to obtain a global dependency statement set; or, based on the input and output port signals declared in each file, cross-file dependency tracing is expanded, the single-file tracing results of each file are concatenated to obtain the cross-file tracing results corresponding to the initial target signal, and then in the top-level file corresponding to the subsystem design file set, the cross-file tracing results corresponding to each initial target signal are summarized and merged to obtain a global dependency statement set.

[0246] In another possible implementation of this application embodiment, the traceability module 71 is specifically used for:

[0247] Initialize the processing queue, the set of visited signals, and the result collector; wherein, the initialized processing queue contains each initial target signal in the initial target signal set, and the initialized set of visited signals and the result collector are both empty sets;

[0248] For any file in the subsystem design file set, repeat the following operation until the processing queue is empty, then extract the relevant statements from the result collector as the single-file trace result:

[0249] Take a signal from the processing queue as the signal to be processed, and add the signal to be processed to the set of visited signals;

[0250] Based on the signal to be processed, each statement in the file is scanned, and statements that meet the preset rules are added to the result collector as relevant statements.

[0251] In another possible implementation of this embodiment, the traceability module 71 is further used for:

[0252] If the signal to be processed is not in the set of visited signals, then the signal to be processed will be added to the set of visited signals.

[0253] And / or,

[0254] Parse the candidate signals corresponding to the relevant statements and update the processing queue based on the candidate signals; the candidate signals are other signals that have a logical causal relationship with the file, other than the initial target signal.

[0255] In another possible implementation of this application embodiment, the traceability module 71 is specifically used for:

[0256] Initialize the current signal set and the global dependency library; the initialized current signal set contains all the initial target signals, and the initialized global dependency library is an empty set.

[0257] Repeat the following operation until the current signal set is empty. Then, retrieve the single-file tracing result of the top-level file corresponding to the subsystem design file set, combine it with the input and output port signals to complete the hierarchical mapping, and concatenate the single-file tracing results of each file in the global dependency library to obtain the cross-file tracing result corresponding to the initial target signal:

[0258] For any file in the subsystem design file set, retrieve the single file traceability result corresponding to the file and merge the single file traceability result into the global dependency library;

[0259] From the single file tracing results, filter out the input and output port signals declared in the file.

[0260] In another possible implementation of this application embodiment, the traceability module 71 is further used for:

[0261] During each iteration, a temporary new set of interface signals is created, and the selected input and output port signals are added to the new set of interface signals.

[0262] The new set of interface signals is deduplicated, and the current set of signals is updated based on the deduplicated new set of interface signals to complete the configuration of the tracking basis for the next round of cross-file dependency tracing.

[0263] In another possible implementation of this application embodiment, the reconstruction module 72 is specifically used for:

[0264] Based on grammatical features, classify each related statement in the global dependency statement set to obtain at least one set of related statements;

[0265] For each set of related statements, select the template with the highest fit from the preset template library as the target template;

[0266] The target templates are populated based on relevant statements, and the populated target templates are integrated to obtain the filtered design.

[0267] In another possible implementation of this application embodiment, the reconstruction module 72 is specifically used for:

[0268] The syntax features corresponding to each group of related statements are compared with the syntax matching features of each template in the preset template library, and the feature matching degree is calculated.

[0269] The template with the highest feature matching degree is determined as the target template.

[0270] Another possible implementation of this application embodiment includes at least one of the following syntax features: keywords, assignment types, and structural information of the original file; and / or, the preset template library includes at least one of the following: continuous assignment templates, conditional branch templates, selection statement templates, procedure block templates, and generation block templates.

[0271] In another possible implementation of this application embodiment, the generation module 73 is specifically used for:

[0272] Based on the filtered design, the initial target signal set, and the pre-defined verification engineering constraints, a structured task instruction package is constructed. The structured task instruction package includes the core tasks of model role positioning and stimulus sequence generation, standardized technical constraints, and contextual information related to the filtered design.

[0273] Based on the structured task instruction package, repeat the following process until the coverage reaches a preset threshold and / or the number of iterations reaches a preset number, then stop the iteration and obtain the stimulus sequence:

[0274] The structured task instruction package is sent to the large language model to generate the initial excitation sequence for the uncovered points corresponding to the initial target signal set;

[0275] The initial stimulus sequence is integrated into the subsystem-level test environment. Compilation and simulation verification are completed based on the original design code corresponding to the subsystem design file set, and the current verification coverage is collected synchronously.

[0276] If an error is detected in the initial stimulus sequence during the verification process, the diagnostic information corresponding to the error is captured and fed back to the large language model to obtain the cause of the defect. Based on the cause of the defect, the initial stimulus sequence is repaired, optimized or regenerated, and the corrected stimulus sequence is used as the new initial stimulus sequence.

[0277] If the initial stimulus sequence is found to have completed compilation and simulation verification without errors, the verification coverage is updated based on the original design code, and the iteration count is updated synchronously.

[0278] In another possible implementation of this application embodiment, the generation module 73 is specifically used for:

[0279] At least two heterogeneous large language models are invoked in parallel to obtain corresponding candidate excitation sequences based on the filtered design and the initial target signal set, respectively.

[0280] Based on each candidate stimulus sequence, the stimulus sequence is determined.

[0281] In another possible implementation of this application embodiment, the generation module 73 is further used for:

[0282] The large language model combines the filtered causal logic with the information of uncovered points corresponding to the initial target signal set to infer whether uncovered points can be activated by legitimate stimuli.

[0283] If it is inferred that the uncovered points cannot be activated by legitimate incentives due to design limitations, an exemption suggestion is generated. The exemption suggestion is presented in the form of structured annotations, clearly indicating the reasons for the exemption and the corresponding design logic basis.

[0284] Based on each exemption recommendation, an exemption report is generated and marked in the coverage database. This is used to exclude uncovered points with reasonable exemptions during the subsequent collection and updating of coverage.

[0285] In another possible implementation of this application embodiment, the generation module 73 is specifically used for:

[0286] Collect all exemption suggestions to generate an exemption candidate point report, and submit the exemption candidate point report to the manual review stage;

[0287] If a candidate point for exemption is confirmed as a reasonable exemption after manual review, the candidate point for exemption will be marked in the coverage database using an automated script;

[0288] Accordingly, the generation module 73 is also used for:

[0289] If the manual review determines that the exemption candidate point is unreasonable, the review opinion will be fed back to the large language model. The large language model will then optimize the incentive sequence generation logic based on the review opinion and continue to execute the incentive sequence generation and iteration process.

[0290] The present application provides a subsystem-level stimulus sequence verification device, which is applicable to the above-described subsystem-level stimulus sequence verification method embodiment, and will not be described again here.

[0291] This application provides an electronic device. Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 8 As shown, Figure 8 The illustrated electronic device includes a processor 81 and a memory 82. The processor 81 and the memory 82 are connected, for example, via a bus 83. Optionally, the electronic device may also include a transceiver 84. It should be noted that in practical applications, the transceiver 84 is not limited to one type, and the structure of this electronic device does not constitute a limitation on the embodiments of this application.

[0292] Processor 81 may be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 81 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0293] Bus 83 may include a pathway for transmitting information between the aforementioned components. Bus 83 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Bus 83 may be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by only one thick line, but this does not mean that there is only one bus 83 or one type of bus 83.

[0294] The memory 82 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0295] The memory 82 is used to store application code that executes the solution of this application, and its execution is controlled by the processor 81. The processor 81 is used to execute the application code stored in the memory 82 to implement the content shown in the foregoing method embodiments.

[0296] This application also provides a computer-readable storage medium, which may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Specifically, the computer-readable storage medium stores program instructions, which are used to implement the methods in the above embodiments.

[0297] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the technical solution of the above method embodiments. Its implementation principle and technical effects are similar, and will not be repeated here.

[0298] This application also provides a subsystem-level excitation sequence verification system in its embodiments. Figure 9 This is a schematic diagram of the structure of a subsystem-level excitation sequence verification system provided in an embodiment of this application. Figure 9 As shown, the system includes:

[0299] The signal tracing module is used to obtain a global set of dependency statements based on an initial set of target signals and a set of subsystem design files, through single-file signal dependency tracing or cross-file recursive dependency tracing; wherein, the initial target signals are obtained based on information of uncovered points;

[0300] The code structure reconstruction module is used to obtain a set of global dependency statements, remove irrelevant code from the set of global dependency statements and complete syntax, resulting in a filtered design; the filtered design is a design file that only contains the causal relationship logic of the initial target signal.

[0301] The excitation generation module is used to obtain an excitation sequence for uncovered points based on the filtered design and the initial target signal set.

[0302] The verification module is used to perform subsystem-level register transfer-level verification based on the stimulus sequence.

[0303] It should be understood that the module mentioned in this embodiment is not the same concept as the module in the aforementioned device embodiment. The two are a correspondence between execution carrier and abstract functional definition. The module in the aforementioned device embodiment is a virtual functional module that implements the verification method of this application. It is only an abstract functional decomposition and definition. The system module in this embodiment is an execution module that carries the corresponding function of the aforementioned virtual functional module. It is a specific functional carrier that implements the verification method of this application and is not a simple virtual module definition.

[0304] In practical applications, in addition to implementing the reverse tracing algorithm of this application, the signal tracing module also supports forward tracing, that is, starting from a specified input port, analyzing the signal propagation path to predict the range of excitation influence or to perform controllability analysis. This application does not limit this aspect.

[0305] The system described in this application can accurately extract the core causal logic corresponding to the uncovered points through the coordinated operation of various modules, generate highly targeted stimulus sequences, and efficiently complete subsystem-level RTL verification. It not only effectively solves the problems of irrelevant code interference, strong blindness in stimulus generation, and slow coverage convergence in traditional verification methods, improving the efficiency of stimulus sequence generation and verification coverage, but also has excellent robustness and engineering adaptability. It can be adapted to industrial-grade subsystem designs with various on-chip interconnect protocols, and supports extended functions such as forward and reverse signal tracing. It can effectively reduce verification costs and engineering risks, and provide an efficient and reliable integrated solution for subsystem-level verification.

[0306] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0307] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for verifying subsystem-level excitation sequences, characterized in that, The method includes: The initial target signal set and the subsystem design file set are input into the signal tracing module. Through single-file signal dependency tracing or cross-file recursive dependency tracing, a global dependency statement set is obtained. The initial target signal is obtained based on the information of uncovered points. The global dependency statement set is input into the code structure reconstruction module, irrelevant code in the global dependency statement set is removed and syntax completion is performed to obtain the filtered design; the filtered design is a design file that only contains the causal relationship logic of the initial target signal. The filtered design and the initial target signal set are input into the excitation generation module to obtain the excitation sequence for the uncovered points; Subsystem-level register transfer-level verification is performed based on the stimulus sequence.

2. The method according to claim 1, characterized in that, The process of tracing dependencies through single-file signal dependencies or cross-file recursive dependencies yields a global set of dependency statements, including: For each initial target signal in the initial target signal set, signal dependency reverse tracing is performed based on each file in the subsystem design file set to extract relevant statements in each file that have a logical causal relationship with the initial target signal, which are used as the single file tracing results for each file. The single-file tracing results corresponding to each of the aforementioned files are summarized and merged to obtain the global dependency statement set; or, based on the input and output port signals declared by each of the aforementioned files, cross-file dependency tracing expansion is performed, and the single-file tracing results of each of the aforementioned files are concatenated to obtain the cross-file tracing result corresponding to the initial target signal. Then, in the top-level file corresponding to the subsystem design file set, the cross-file tracing results corresponding to each of the initial target signals are summarized and merged to obtain the global dependency statement set.

3. The method according to claim 2, characterized in that, The step involves performing signal dependency reverse tracing on each file in the subsystem design file set to extract relevant statements within each file that have a logical causal relationship with the initial target signal, including: Initialize the processing queue, the set of visited signals, and the result collector; wherein, the initialized processing queue contains each of the initial target signals in the initial target signal set, and the initialized set of visited signals and the result collector are both empty sets; For any file in the subsystem design file set, repeat the following operation until the processing queue is empty, then extract the relevant statements from the result collector as the single-file traceability result of the file: Take a signal from the processing queue as a signal to be processed, and add the signal to be processed to the set of accessed signals; Based on the signal to be processed, each statement in the file is scanned, and statements in the file that meet the preset rules are added to the result collector as the relevant statements.

4. The method according to claim 3, characterized in that, The method further includes: If the signal to be processed is not in the set of visited signals, then it is determined to add the signal to be processed to the set of visited signals. And / or, The candidate signals corresponding to the relevant statements are parsed, and the processing queue is updated based on the candidate signals; the candidate signals are other signals that have a logical causal relationship with the file, other than the initial target signal.

5. The method according to any one of claims 2-4, characterized in that, The process of performing cross-file dependency tracing expansion based on the input and output port signals declared in each of the aforementioned files, and concatenating the single-file tracing results of each of the aforementioned files, includes: Initialize the current signal set and the global dependency library; wherein, the initialized current signal set contains each of the initial target signals, and the initialized global dependency library is an empty set; Repeat the following operation until the current signal set is empty: retrieve the single-file tracing result of the top-level file corresponding to the subsystem design file set, combine it with the input and output port signals to complete the hierarchical mapping, and concatenate the single-file tracing results of each file in the global dependency library to obtain the cross-file tracing result corresponding to the initial target signal: For any file in the subsystem design file set, retrieve the single file traceability result corresponding to the file, and merge the single file traceability result into the global dependency library; From the single file tracing results, the input and output port signals declared in the file are filtered out.

6. The method according to claim 5, characterized in that, In each iteration, the method further includes: Create a temporary new set of interface signals, and add the selected input and output port signals to the new set of interface signals; The new interface signal set is deduplicated, and the current signal set is updated based on the deduplicated new interface signal set to complete the configuration of the tracking basis for the next round of cross-file dependency tracing.

7. The method according to any one of claims 1-4, characterized in that, The process of removing irrelevant code from the global dependency statement set and performing syntax completion to obtain the filtered design includes: Based on grammatical features, each related statement in the global dependency statement set is classified to obtain at least one set of related statements; For each set of related statements, select the template with the highest fit from the preset template library as the target template; The target template is populated based on the relevant statements, and the populated target templates are integrated to obtain the filtered design.

8. The method according to claim 7, characterized in that, The step of selecting the template with the highest compatibility from the preset template library as the target template includes: The grammatical features corresponding to each group of related statements are compared with the grammatical matching features of each template in the preset template library, and the feature matching degree is calculated. The template with the highest feature matching degree is determined as the target template.

9. The method according to claim 7, characterized in that, The grammatical features include at least one of keywords, assignment types, and structural information of the original file; and / or, the preset template library includes at least one of continuous assignment templates, conditional branch templates, selection statement templates, procedure block templates, and generation block templates.

10. The method according to any one of claims 1-4, characterized in that, The step of inputting the filtered design and the initial target signal set into the excitation generation module to obtain the excitation sequence for the uncovered points includes: Based on the filtered design, the initial target signal set, and the preset verification engineering constraints, a structured task instruction package is constructed; the structured task instruction package includes model role positioning, core tasks of stimulus sequence generation, standardized technical constraints, and contextual information related to the filtered design. Based on the structured task instruction package, repeat the following process until the coverage reaches a preset threshold and / or the number of iterations reaches a preset number, then stop the iteration and obtain the stimulus sequence: The structured task instruction package is sent to the large language model to generate an initial excitation sequence for the uncovered points corresponding to the initial target signal set; The initial stimulus sequence is integrated into the subsystem-level test environment. Compilation and simulation verification are completed based on the original design code corresponding to the subsystem design file set, and the current verification coverage is collected synchronously. If an error is detected in the initial stimulus sequence during the verification process, the diagnostic information corresponding to the error is captured and fed back to the large language model to obtain the cause of the defect and repair, optimize or regenerate the initial stimulus sequence based on the cause of the defect, and use the corrected stimulus sequence as the new initial stimulus sequence. If the initial stimulus sequence is found to have completed compilation and simulation verification without errors, the verification coverage is updated based on the original design code, and the iteration count is updated synchronously.

11. The method according to any one of claims 1-4, characterized in that, The step of inputting the filtered design and the initial target signal set into the excitation generation module to obtain the excitation sequence for the uncovered points includes: At least two heterogeneous large language models are invoked in parallel to obtain corresponding candidate excitation sequences based on the filtered design and the initial target signal set, respectively. The stimulus sequence is determined based on each of the candidate stimulus sequences.

12. The method according to claim 10, characterized in that, The method further includes: The large language model combines the causal relationship logic designed after filtering with the information of uncovered points corresponding to the initial target signal set to infer whether the uncovered points can be activated by legitimate stimuli. If it is inferred that the uncovered point cannot be activated by a legitimate incentive due to design limitations, an exemption suggestion is generated; the exemption suggestion is presented in the form of structured annotations, clearly indicating the reasons for the exemption and the corresponding design logic basis; Based on the aforementioned exemption recommendations, an exemption report is generated and marked in the coverage database for use in the subsequent collection and updating of coverage to exclude uncovered points for reasonable exemptions.

13. The method according to claim 12, characterized in that, The process of generating an exemption report based on each of the exemption recommendations includes: Collect all the aforementioned exemption suggestions to generate an exemption candidate point report, and submit the exemption candidate point report to the manual review stage; If the exemption candidate point is confirmed as a reasonable exemption by manual review, the exemption candidate point is marked in the coverage database by an automated script; Accordingly, the method further includes: If the manual review determines that the exemption candidate point is unreasonable, the review opinion will be fed back to the large language model, which will then optimize the incentive sequence generation logic based on the review opinion and continue to execute the incentive sequence generation and iteration process.

14. A verification system for subsystem-level excitation sequences, characterized in that, The system includes: The signal tracing module is used to obtain a global dependency statement set based on an initial target signal set and a subsystem design file set, through single-file signal dependency tracing or cross-file recursive dependency tracing; wherein, the initial target signal is obtained based on uncovered point information; The code structure reconstruction module is used to obtain the global dependency statement set, remove irrelevant code from the global dependency statement set and complete the syntax, and obtain the filtered design; the filtered design is a design file that only contains the causal relationship logic of the initial target signal. The excitation generation module is used to obtain an excitation sequence for the uncovered points based on the filtered design and the initial target signal set. The verification module is used to perform subsystem-level register transfer-level verification based on the stimulus sequence.

15. An electronic device, characterized in that, include: At least one processor and memory; The memory stores computer-executed instructions; The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the method as described in any one of claims 1 to 13.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a central processing unit, are used to implement the method as described in any one of claims 1 to 13.

17. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 13.