A processor load store unit functional verification method and device, electronic equipment and storage medium

Abstract

The application relates to the technical field of function verification, in particular to a processor load storage unit function verification method and device, electronic equipment and a storage medium, the method comprising the following steps: performing formal verification on a processor load storage unit through a formal verification tool, and extracting feature data of an uncovered critical path; wherein the feature data at least comprises timing features, address features and data dependency features; converting the feature data into constraint rules available for a dynamic simulation platform, and generating a test stimulus; performing dynamic simulation verification based on the test stimulus, and obtaining a coverage result. The processor load storage unit function verification method provided by the application cooperates with a dynamic simulation closed loop through formal verification, generates directional constraints by extracting critical path features, greatly shortens a verification period, and improves coverage convergence efficiency.

Description

Technical Field

[0001] This invention relates to the field of functional verification technology, and in particular to a method, apparatus, electronic device, and storage medium for verifying the functionality of a processor loading memory unit. Background Technology

[0002] In the verification of Load Memory Unit (LSU) of RISC-V architecture processors, traditional dynamic simulation relies on random constraints. It is generally difficult to achieve convergence in verification coverage for complex scenarios such as various memory attributes, address overlap, dependencies between read and write instructions, parallel processing between multiple pipelines, and memory consistency in multi-core systems.

[0003] Existing technologies attempt to optimize the verification process through regression testing combined with manual intervention. Specifically, this includes: 1) analyzing code coverage and functional coverage reports generated by dynamic simulation to locate low-coverage areas; 2) manually adjusting constraint weights (e.g., forcibly increasing the probability of address overlap scenarios); and 3) constructing targeted test cases to cover specific scenarios through waveform debugging. However, these methods have significant drawbacks: First, manually analyzing coverage reports requires checking tens of thousands of coverage points one by one. For complex designs like LSUs, engineers may spend weeks without identifying all problem points. Second, some logically uncoverable scenarios (e.g., specific out-of-order instruction sequences whose paths do not exist due to hardware design limitations) require repeated verification and elimination, resulting in wasted resources. More seriously, when there are too many random variables (e.g., memory access order between multi-cores, multi-cycle pipeline timing constraints), even with significant computational resources, verification time remains difficult to control, and the high proportion of redundant test cases further hinders convergence efficiency. These contradictions highlight the unsustainability of existing methods in large-scale LSU verification.

[0004] To address the aforementioned technical challenges, existing technologies attempt to combine formal verification tools (such as JasperGold) with dynamic simulation. While formal methods can theoretically exhaustively explore the state space through symbolic execution, they still face the "state explosion" problem. Relying solely on dynamic simulation, although reducing complexity, requires a massive number of randomized test cases to cover all possible paths. This not only consumes significant computational resources but also fails to effectively locate deep-seated dependency vulnerabilities (such as address conflicts occurring after multiple cycles). Furthermore, existing tools lack intelligent coverage guidance mechanisms, requiring engineers to rely on manual experience to write corner case test cases, resulting in slow convergence and difficulty in quantifying verification completeness. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a method, apparatus, electronic device, and storage medium for verifying the functionality of a processor loading storage unit.

[0006] In a first aspect, embodiments of the present invention provide a method for verifying the functionality of a processor loading memory unit, the method comprising:

[0007] Formal verification tools are used to perform formal verification on the processor's loaded memory units to extract feature data of the uncovered critical paths; the feature data includes at least timing features, address features, and data dependency features.

[0008] The feature data is converted into constraint rules usable by the dynamic simulation platform to generate test stimuli;

[0009] Dynamic simulation verification is performed based on test stimuli to obtain coverage results;

[0010] By comparing formal path characteristics with dynamic simulation coverage, it can be determined whether there are any uncovered paths.

[0011] If so, the hybrid verification mode is triggered and fed back to the formal verification tool to perform loop verification until the path is fully covered, thus completing the verification.

[0012] In conjunction with the first aspect, the steps of formally verifying the processor's loaded memory units using formal verification tools and extracting feature data from uncovered critical paths include:

[0013] Identify at least one core signal in the formal counterexample waveform that is associated with the uncovered critical path;

[0014] For each core signal, obtain the core signal's address bus, data dependency flag, and pipeline conflict signal;

[0015] Analyze the formal counterexample waveforms to extract the conflict signals, timing features, and address features containing boundary address values ​​from the address bus;

[0016] By analyzing the full path Load-Store instructions through the dependency graph, the length of the longest dependency chain is calculated. At the same time, when there is a closed loop in the dependency graph and all instructions in the loop are in a suspended state, a deadlock point is marked.

[0017] By combining the length of the longest dependency chain and the deadlock point, the data dependency characteristics are determined.

[0018] In conjunction with the first aspect, prior to the step of identifying at least one path-related core signal in the waveform, the method further includes:

[0019] A dynamic compression algorithm based on signal change rate is used to merge adjacent events with a time difference less than a specified difference to generate a simplified counterexample waveform.

[0020] In conjunction with the first aspect, the steps of converting feature data into constraint rules usable by the dynamic simulation platform and generating test stimuli with random weights include:

[0021] The feature data is transformed using a constraint transformation script to obtain constraint rules that can be executed by the dynamic simulation platform.

[0022] The constraint weights of the constraint rules are dynamically adjusted using the Actor-Critic reinforcement learning framework.

[0023] Real-time weight optimization is performed on high-risk paths with formalized labels.

[0024] In conjunction with the first aspect, the constraint rules include address constraints, timing constraints, and dependency constraints;

[0025] The steps involved in transforming feature data using a constraint transformation script to obtain constraint rules executable by the dynamic simulation platform include:

[0026] The address features are set as the high-risk path address set of the dynamic simulation platform constraints to construct address constraints;

[0027] Increase the weight of time-series features by a specified percentage, increase the weight of the Load-store sequence, and construct dependency constraints based on the length of the longest dependency chain.

[0028] In conjunction with the first aspect, the steps to trigger the hybrid verification mode to the formal verification tool include:

[0029] Locate the timing window for uncovered paths;

[0030] Freeze the dynamic simulation within the timing window and switch to a formal verification tool for local in-depth verification;

[0031] Extract new counterexample features generated by local deep validation;

[0032] Based on the address characteristics and data dependency characteristics of new counterexamples, the constraint rules are dynamically updated.

[0033] In conjunction with the first aspect, after comparing formal path characteristics with dynamic simulation coverage to determine whether there are uncovered paths, the process also includes:

[0034] If not, confirm that the storage unit loading verification is complete, and reset the constraint weights of the constraint rules to their base values.

[0035] Secondly, this application provides a processor loading memory unit function verification device, the device comprising:

[0036] The formal verification module is used to perform formal verification on the processor's loaded memory units using formal verification tools, and to extract feature data of the uncovered critical paths; wherein, the feature data includes at least timing features, address features, and data dependency features;

[0037] The dynamic conversion module is used to convert feature data into constraint rules for the dynamic simulation platform and generate test stimuli.

[0038] The execution module is used to perform dynamic simulation verification based on test stimuli to obtain coverage results;

[0039] The judgment module is used to compare the formal path features with the dynamic simulation coverage to determine whether there are any uncovered paths.

[0040] The trigger verification module is used to trigger a hybrid verification mode to feed back to the formal verification tool when there are uncovered paths, so as to perform cyclic verification until the paths are fully covered and the verification is completed.

[0041] Thirdly, this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor runs the computer program to cause the electronic device to perform the above-described method.

[0042] Fourthly, this application provides a readable storage medium storing computer program instructions, which are read and executed by a processor to perform the above-described method.

[0043] The embodiments of the present invention bring the following beneficial effects: The present application provides a method, apparatus, electronic device, and storage medium for verifying the functionality of a processor loading memory unit. The method includes: performing formal verification on the processor loading memory unit using a formal verification tool to extract feature data of uncovered critical paths; wherein, the feature data includes at least timing features, address features, and data dependency features; converting the feature data into constraint rules usable by a dynamic simulation platform to generate test stimuli; performing dynamic simulation verification based on the test stimuli to obtain coverage results; comparing the formal path features with the dynamic simulation coverage to determine whether there are uncovered paths; if so, triggering a hybrid verification mode to feed back to the formal verification tool to iteratively verify until the path is fully covered, thus completing the verification.

[0044] The processor loading memory unit functional verification method provided in this application significantly shortens the verification cycle and improves coverage convergence efficiency by combining formal verification with dynamic simulation in a closed loop and extracting key path features (timing, address, and data dependencies) to generate directional constraints.

[0045] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0046] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0048] Figure 1 A flowchart illustrating a processor loading memory unit function verification method provided in an embodiment of the present invention;

[0049] Figure 2 This is a schematic diagram of the structure of the processor loading memory unit function verification device provided in an embodiment of the present invention;

[0050] Figure 3 This is a schematic diagram of the electronic device structure provided in an embodiment of the present invention;

[0051] Figure 4 This is a schematic diagram of the overall process of the processor loading memory unit function verification method provided in an embodiment of the present invention.

[0052] Figure label:

[0053] 10 - Formal verification module, 20 - Dynamic transformation module, 30 - Execution module, 40 - Judgment module, 50 - Trigger verification module;

[0054] 130 - Processor, 131 - Memory, 132 - Bus, 133 - Communication interface. Detailed Implementation

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

[0056] To facilitate understanding of this embodiment, the technical terms used in this application will be briefly introduced below.

[0057] The LSU (Load Store Unit) is responsible for executing all load and store instructions, generating virtual addresses for load and store operations, and loading data from memory or storing data from registers back to memory.

[0058] RSIC-V is an open-source Reduced Instruction Set Computer (RISC) architecture.

[0059] After introducing the technical terms used in this application, the application scenarios and design concepts of the embodiments of this application will be briefly described below.

[0060] Formal verification can exhaustively enumerate the state space, but it has limitations for superscalar multi-issue architectures (such as 4-way superscalars), where the number of state combinations grows exponentially. Jasper Gold used more than 48GB of memory when verifying a dual-issue 10-stage pipeline, which caused the state space to explode, making it impossible to complete the full state traversal and directly generate the test stimuli required for dynamic simulation.

[0061] Dynamic simulation relies on random test vectors, which makes it difficult to cover complex LSU scenarios (such as non-aligned address access and atomic operation conflicts), resulting in lengthy verification cycles and low verification efficiency.

[0062] Based on this, this application provides a method, apparatus, electronic device, and storage medium for verifying the functionality of a processor loading storage unit. It actively analyzes coverage vulnerabilities using formal tools, outputs key feature data, and automatically converts it into dynamic simulation constraint rules to optimize constraint weights for dynamic simulation verification. Based on the dynamic simulation verification results, it provides feedback to form a closed-loop verification process, thereby achieving rapid coverage convergence.

[0063] Example 1

[0064] This application provides a method for verifying the processor loading memory unit function, combined with... Figure 1 As shown, the method includes:

[0065] S110 uses a formal verification tool to perform formal verification on the processor's loaded memory unit and extracts feature data of the uncovered critical path; wherein, the feature data includes at least timing features, address features, and data dependency features.

[0066] S120 converts feature data into constraint rules usable by the dynamic simulation platform to generate test stimuli.

[0067] S130 performs dynamic simulation verification based on test stimuli to obtain coverage results.

[0068] S140. Compare the formal path features with the dynamic simulation coverage to determine whether there are any uncovered paths.

[0069] If so, proceed to step S150.

[0070] S150 triggers the hybrid verification mode to feed back to the formal verification tool, which then performs loop verification until the path is fully covered, thus completing the verification.

[0071] First, the feature data of the output key paths is actively analyzed using formal tools, and this feature data is converted into self-dynamic simulation constraint rules. This guides the dynamic simulation platform to generate test stimuli for uncovered paths. The constraint rule-driven simulation collects coverage results, which are compared with the formal path features. If any uncovered paths remain, the simulation information is fed back to the formal tools to update the constraint rules and restart the process until all paths are covered. In this way, vulnerabilities are discovered based on formal functional verification, and targeted testing is conducted based on dynamic simulation, forming a two-way feedback closed-loop optimization, aiming to efficiently and thoroughly cover all critical paths.

[0072] In step S110, the formal verification tool can be Cadence JasperGold, Synopsys VCFormal, Siemens EDA Questa Formal, etc. When exhaustively searching the state space, the formal verification tool identifies which paths (or attributes) it failed to prove or disprove (i.e., "uncovered"). Unlike traditional formal verification which simply reports pass / fail or counterexamples, it extracts feature data of the critical paths not covered by formal verification. Feature data includes at least: timing features, address features, and data dependency features. Timing features refer to the timing characteristics of the path, such as which clock cycles are involved, setup / hold time relationships, critical path delays, etc. Address features refer to the specific address ranges involved in the path, address alignment methods, address conflict conditions, etc. Data dependency features refer to the path's dependency on loaded / stored data, such as specific data values, data patterns (e.g., all 0s, all 1s, address-related data), data race conditions, etc. That is, step S110 uses the “exhaustiveness” of formal verification to discover complex or peripheral scenes that may be missed by dynamic simulation, and extracts the key attributes (features) of these scenes.

[0073] In conjunction with the first aspect, step S110 includes:

[0074] S111, Identify at least one core signal in the formal counterexample waveform that is related to the uncovered critical path.

[0075] S112, for each core signal, obtains the core signal's address bus, data dependency flag, and pipeline conflict signal.

[0076] S113, analyze the formal counterexample waveform, and extract the conflict signals, timing characteristics, and address characteristics containing boundary address values ​​of the address bus.

[0077] S114 analyzes the full-path Load-Store instructions through the dependency graph, calculates the length of the longest dependency chain, and marks deadlock points when there are closed loops in the dependency graph and all instructions in the loop are in a suspended state.

[0078] S115, combine the length of the longest dependency chain and the deadlock point to determine the data dependency characteristics.

[0079] Step S111 automatically identifies core signals strongly related to uncovered paths. Subsequently, step S112 extracts features from the core signals. Specifically, it extracts the address bus by extracting the access address range, alignment method, and cross-boundary behavior (e.g., unaligned access of addresses 0x1000-0x1003); extracts data dependency flags based on data value constraints and read / write data matching relationships (e.g., a conflict is triggered when Store data must be 0xFF); and extracts conflict signals by bus contention and resource contention flags (e.g., two load instructions simultaneously request the same cache line).

[0080] Subsequently, step S113 performs in-depth analysis of the address bus, and further extracts the address features of the address bus, including conflict signals, timing characteristics, and boundary address values, through timing detection and conflict type classification.

[0081] Step S114 analyzes nodes and edges based on the dependency graph to determine data dependencies and calculate dependency depth to obtain the longest dependency chain and identify closed loops. If a closed loop exists and each instruction in the closed loop is in a suspended state, a deadlock point is marked. Then, in step S115, data dependency features are synthesized based on the obtained longest dependency chain length and deadlock point (e.g., deadlock is triggered when address 0x2000 and data is 0x0).

[0082] In this way, dependency graph closed-loop detection exposes hidden system-level deadlock risks that are extremely difficult to trigger in traditional dynamic simulation verification processes. The above steps transform formal counterexamples into accurate feature data sources required for dynamic simulation.

[0083] In conjunction with the first aspect, prior to step S111, the following also includes:

[0084] S1110 employs a dynamic compression algorithm based on signal change rate to merge adjacent events with timing differences less than a specified difference, thereby generating a simplified counterexample waveform.

[0085] Understandably, by merging adjacent events with timing differences less than a threshold (such as small clock offsets on the same data bus), large counterexample waveforms can be simplified into smaller counterexample waveforms, retaining key events and eliminating redundant transitions. This solves the problem of excessive formal counterexample waveform data, reducing the complexity of subsequent signal analysis and avoiding noise interference in core feature extraction.

[0086] In this embodiment, a difference of 10% is specified, meaning that adjacent events with a timing difference of less than 10% are merged into a single event. For example, when the address bus change amplitude is less than 5% over multiple consecutive clock cycles, they are merged into a single event.

[0087] In conjunction with the first aspect, step S120 includes:

[0088] S121, the feature data is transformed through the constraint transformation script to obtain the constraint rules that can be executed by the dynamic simulation platform.

[0089] S122 uses the Actor-Critic reinforcement learning framework to dynamically adjust the constraint weights of the constraint rules.

[0090] S123, performs real-time weight optimization on formally labeled high-risk paths.

[0091] In conjunction with the first aspect, the constraint rules include address constraints, timing constraints, and dependency constraints; step S121 includes:

[0092] S1211 sets the address features as the high-risk path address set of the dynamic simulation platform constraints to construct address constraints.

[0093] S1212 increases the weight of time-series features by a specified percentage, the weight of the Load-store sequence, and constructs dependency constraints based on the length of the longest dependency chain.

[0094] After formal verification and output feature data conversion in step S110, step S120 converts the feature data into constraint rules executable by the dynamic simulation platform. Subsequently, constraint weights are adjusted and weights of high-risk paths are optimized based on the pre-configured Actor-Critic reinforcement learning framework.

[0095] Specifically, the address features containing boundary addresses extracted in step S110 are prioritized as the high-risk path address set to construct address constraints. Understandably, when converting feature data into constraint rules, initial weights are assigned to address features, data dependency features, and conflict signals, and then the weights corresponding to each feature are adjusted. Simultaneously, dependency constraints are constructed using the longest dependency chain length obtained from formal verification.

[0096] Subsequently, the weighting of temporal features in formal counterexamples and the weighting of Load-store sequences in the formally extracted critical paths are increased. The weighting of Load-store sequences includes the frequency relationship between Load (data read) and Store (data write) instructions, and the priority distribution of instruction sequence patterns (such as consecutive Loads and alternating Load-Stores), all of which directly affect the coverage of the Load Storage Unit (LSU) critical path.

[0097] Next, step S122 uses a preset Actor-Critic framework in the Dynamic Simulation Platform (UVM) to adjust the constraint weights of each constraint rule in the action space based on relevant parameters in the state space. The state space includes the current coverage progress, the progress of uncovered paths, and the constraint conflict count. Specifically, the dynamic simulation platform runs simulation verification based on the constraint rules obtained in step S121 to obtain the coverage progress, the criticality of uncovered paths, and the constraint conflict count for this verification, thereby optimizing the constraint weights. Subsequently, in step S123, the constraint weights of formally marked high-risk paths are increased according to preset rules. In this embodiment, the preset rule is to increase the constraint weights of high-risk paths by 50%-100%, while simultaneously decaying the weights by 15% after each test round to prevent local optima. Based on steps S121-S123, the formalized feature data extracted in step S110 is transformed, and appropriate constraint weights and high-risk path implementation weight optimizations are matched to generate test stimuli by combining the above constraints and their constraint weights, thereby accurately constraining the dynamic simulation platform for functional verification. Subsequently, step S130 obtains the coverage results obtained by the dynamic simulation platform using the test stimulus generated in step S120.

[0098] Step S140 compares the coverage result obtained in step S130 with the formal path features to determine whether the coverage meets the standard, i.e. whether there are still uncovered paths.

[0099] In conjunction with the first aspect, step S150 includes:

[0100] S151, locate the timing window of the uncovered path.

[0101] S152, freeze the dynamic simulation within the timing window and switch to a formal verification tool for local in-depth verification.

[0102] S153, extract new counterexample features generated by local deep verification.

[0103] S154 dynamically updates constraint rules based on the address characteristics and data dependency characteristics of new counterexamples.

[0104] Understandably, when uncovered paths exist, simulation information is fed back to formal tools to refine constraints. This involves restarting formal verification, converting feature data into constraint rules, adjusting and optimizing constraint weights, and conducting dynamic simulation verification. Coverage results are compared with formal features to determine if any critical paths remain uncovered… until all paths are covered, completing functional verification. In this way, vulnerabilities are discovered through iterative formal verification, targeted testing is conducted using dynamic simulation, and rapid convergence is achieved through bidirectional feedback closed-loop optimization, thus improving the verification rate.

[0105] If there are still uncovered paths after feedback, firstly, the timing window of the uncovered path can be located based on factors such as signal activity cycle, address orientation range, and key state machine transitions. This has high positioning accuracy and improves the address range identification accuracy. Subsequently, when performing dynamic simulation verification for this timing window, the register state of the dynamic simulation is directly imported into the formal environment. Local formal verification is used to deeply extract and generate new counterexample features. Then, based on the new counterexample features, the constraint engine is injected to update the constraint rules and constraint weights, thereby dynamically updating the dynamic simulation platform. This achieves millisecond-level switching and intelligent co-evolution between formal verification and dynamic simulation, thereby improving the verification efficiency of Load Memory Unit (LSU).

[0106] In conjunction with the first aspect, after step S140, the following also includes:

[0107] S160, confirm that the loading of the storage unit verification is complete, and reset the constraint weights of the constraint rules to the base values.

[0108] Dynamic simulation tests are performed on the dynamic simulation platform using the generated test stimuli. The comparison results of the coverage results and the formal path features indicate that the path is fully covered and the characterization has been verified. At this point, the constraint weights of the constraint rules are reset to the base values ​​(i.e., the initial values) for the next verification.

[0109] Combination Figure 4 As shown, formal analysis is first performed to extract counterexample features and identify critical paths. Then, data transformation is performed to obtain constraint rules. Subsequently, intelligent constraint optimization is carried out, and dynamic simulation is performed based on the optimized constraint rules. Coverage analysis is then performed, and the results of the coverage analysis (i.e., the aforementioned coverage results) are compared with the formal path features obtained from formal verification to determine whether the coverage meets the standard. If the coverage meets the standard, the verification is considered complete. If the coverage does not meet the standard, the feedback is sent to the formal analysis process. The above steps are repeated until the coverage meets the standard again, thus completing the verification.

[0110] Secondly, this application provides a processor loading memory unit function verification device, combined with Figure 2As shown, the device includes: a formal verification module 10, a dynamic transformation module 20, an execution module 30, a judgment module 40, and a trigger verification module 50.

[0111] The formal verification module 10 is used to perform formal verification on the processor loading memory unit using formal verification tools and extract feature data of the uncovered critical path; wherein, the feature data includes at least timing features, address features and data dependency features.

[0112] The dynamic conversion module 20 is used to convert feature data into constraint rules for the dynamic simulation platform and generate test stimuli.

[0113] The execution module 30 is used to perform dynamic simulation verification based on test stimuli to obtain coverage results.

[0114] The judgment module 40 is used to compare the formal path features with the dynamic simulation coverage to determine whether there are any uncovered paths.

[0115] The trigger verification module 50 is used to trigger a hybrid verification mode to feed back to the formal verification tool when there are uncovered paths, so as to perform cyclic verification until the paths are fully covered and the verification is completed.

[0116] Thirdly, embodiments of this application provide an electronic device, combined with Figure 3 As shown, the electronic device includes a memory 131 and a processor 130. The memory 131 stores a computer program, and the processor 130 runs the computer program to make the electronic device perform the above-described method.

[0117] Furthermore, combined Figure 3 The electronic device shown also includes a bus 132 and a communication interface 133, with the processor 130, the communication interface 133 and the memory 131 connected via the bus 132.

[0118] The memory 131 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 133 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 132 may be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0119] Processor 130 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 130 or by instructions in software form. Processor 130 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 131, and processor 130 reads the information in memory 131 and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0120] Fourthly, embodiments of this application provide a readable storage medium storing computer program instructions, which are read and executed by a processor to perform the above-described method.

[0121] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0122] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0123] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0124] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0125] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for verifying the functionality of a processor loading memory unit, characterized in that, The method includes: Formal verification tools are used to perform formal verification on the processor's load-store units, extracting feature data of uncovered critical paths. This feature data includes at least timing features, address features, and data dependency features. The entire path of Load-Store instructions is analyzed using a dependency graph to calculate the length of the longest dependency chain. Simultaneously, when a closed loop exists in the dependency graph and all instructions within the loop are suspended, a deadlock point is marked. The data dependency features are determined by combining the length of the longest dependency chain and the deadlock point. The feature data is transformed using a constraint transformation script to obtain constraint rules that can be executed by the dynamic simulation platform; the constraint weights of the constraint rules are dynamically adjusted using the Actor-Critic reinforcement learning framework; real-time weight optimization is performed on formally labeled high-risk paths to generate test incentives; Dynamic simulation verification is performed based on the test stimulus to obtain coverage results; By comparing formal path characteristics with dynamic simulation coverage, it can be determined whether there are any uncovered paths. If so, the hybrid verification mode is triggered and fed back to the formal verification tool to perform loop verification until the path is fully covered, thus completing the verification.

2. The method according to claim 1, characterized in that, The steps of formally verifying the processor's loaded memory units using formal verification tools and extracting feature data from uncovered critical paths include: Identify at least one core signal in the formal counterexample waveform that is associated with the uncovered critical path; For each of the core signals, obtain the address bus, data dependency flag, and pipeline conflict signal of the core signal; Analyze the formal counterexample waveforms to extract the conflict signals, timing features, and address features containing boundary address values ​​from the address bus.

3. The method according to claim 2, characterized in that, Prior to the step of identifying at least one path-dependent core signal in the waveform, the method further includes: A dynamic compression algorithm based on signal change rate is used to merge adjacent events with a time difference less than a specified difference to generate a simplified counterexample waveform.

4. The method according to claim 1, characterized in that, Constraint rules include address constraints, timing constraints, and dependency constraints; The steps of transforming feature data using a constraint transformation script to obtain executable constraint rules for the dynamic simulation platform include: The address features are set as the high-risk path address set of the dynamic simulation platform constraints to construct the address constraints; The time-series features are given a specified weight ratio, the load-store sequence is given a weight ratio, and the dependency constraints are constructed based on the length of the longest dependency chain.

5. The method according to claim 1, characterized in that, The steps to trigger a hybrid verification mode to a formal verification tool include: Locate the timing window for uncovered paths; Freeze the dynamic simulation within the time window and switch to a formal verification tool for local in-depth verification; Extract the new counterexample features generated by the local deep verification; The constraint rules are dynamically updated based on the address characteristics and data dependency characteristics of the new counterexamples.

6. The method according to claim 1, characterized in that, After comparing formal path features with dynamic simulation coverage to determine whether there are uncovered paths, the process also includes: If not, confirm that the loading storage unit verification is complete, and reset the constraint weights of the constraint rules to their base values.

7. A processor loading memory unit function verification device, characterized in that, The device includes: The formal verification module is used to perform formal verification on the processor's load-store units using formal verification tools, and to extract feature data of uncovered critical paths. The feature data includes at least timing features, address features, and data dependency features. The module analyzes the entire path of Load-Store instructions through dependency graph analysis, calculates the length of the longest dependency chain, and marks deadlock points when closed loops exist in the dependency graph and all instructions within the loop are in a suspended state. The data dependency features are determined by combining the length of the longest dependency chain and the deadlock points. The dynamic transformation module is used to transform feature data through constraint transformation scripts to obtain constraint rules that can be executed by the dynamic simulation platform; the constraint weights of the constraint rules are dynamically adjusted using the Actor-Critic reinforcement learning framework; real-time weight optimization is performed on formally labeled high-risk paths to generate test incentives; The execution module is used to perform dynamic simulation verification based on the test stimulus to obtain coverage results; The judgment module is used to compare the formal path features with the dynamic simulation coverage to determine whether there are any uncovered paths. The trigger verification module is used to trigger a hybrid verification mode to feed back to the formal verification tool when there are uncovered paths, so as to perform cyclic verification until the paths are fully covered and the verification is completed.

8. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program and the processor running the computer program to cause the electronic device to perform the method of any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium stores computer program instructions, which, when read and executed by a processor, perform the method described in any one of claims 1 to 6.

Images