Conflict verification method and device based on transaction life cycle phase perception, and equipment

Abstract

The present disclosure provides a transaction life cycle phase-aware conflict verification method, device and equipment, relating to the technical field of computers, which comprises: obtaining transaction timing phase tracking data of a target transaction request in a design under test; wherein the transaction timing phase tracking data carries a timestamp and a phase label corresponding to a transaction life cycle phase; determining a target conflict strategy from a preset conflict strategy set based on the phase label and the timestamp; wherein the target conflict strategy corresponds to a conflict sensitive point subsequent to the current transaction life cycle phase; generating a conflict transaction request sequence according to the target conflict strategy and sending the conflict transaction request sequence to the design under test for verification. This method can improve the coverage of conflict scenario verification, overcome the problems of test space explosion and constraint loss effective sequence, and improve verification efficiency and convergence speed.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a conflict verification method, apparatus and device based on transaction lifecycle phase awareness. Background Technology

[0002] Functional verification of multi-core coherent interconnect protocols in SoCs (System-on-Chips) is a crucial step in ensuring system correctness. In related technologies, functional verification typically includes two categories: directed testing and formal verification. Directed testing usually involves manually constructing specific scenarios for functional verification, which struggles to cover complex, contention-boundary scenarios. Formal verification typically involves exhaustively examining the state space using model verification, which often faces the problem of test space explosion, and constraint adjustments can easily result in the loss of effective test sequences. Summary of the Invention

[0003] This disclosure provides a conflict verification method, apparatus, and device based on transaction lifecycle phase awareness.

[0004] According to a first aspect of this disclosure, a conflict verification method based on transaction lifecycle phase awareness is provided, comprising:

[0005] Obtain transaction timing phase tracking data of the target transaction request in the design under test; wherein, the transaction timing phase tracking data carries a timestamp and a phase tag corresponding to the phase of the transaction lifecycle;

[0006] Based on the phase tag and the timestamp, a target conflict strategy is determined from a preset set of conflict strategies; wherein, the target conflict strategy corresponds to a conflict-sensitive point following the current transaction lifecycle phase;

[0007] A conflict transaction request sequence is generated according to the target conflict strategy, and the conflict transaction request sequence is sent to the design under test for verification.

[0008] According to a second aspect of this disclosure, a conflict verification apparatus based on transaction lifecycle phase awareness is provided, comprising:

[0009] The data acquisition module is used to acquire transaction timing phase tracking data of the target transaction request in the design under test; wherein, the transaction timing phase tracking data carries a timestamp and a phase tag corresponding to the phase of the transaction lifecycle;

[0010] The strategy determination module is used to determine a target conflict strategy from a preset set of conflict strategies based on the phase tag and the timestamp; wherein the target conflict strategy corresponds to a conflict-sensitive point following the current transaction lifecycle phase;

[0011] The conflict verification module is used to generate a conflict transaction request sequence according to the target conflict strategy, and send the conflict transaction request sequence to the design under test for verification.

[0012] According to a third aspect of this disclosure, an electronic device is provided, comprising:

[0013] At least one processor; and,

[0014] A memory communicatively connected to the at least one processor; wherein,

[0015] The memory stores instructions that can be executed by the at least one processor, which enables the at least one processor to perform the conflict verification method based on transaction lifecycle phase awareness described in the first aspect above.

[0016] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause the computer to execute the conflict verification method based on transaction lifecycle phase awareness described in the first aspect above.

[0017] According to a fifth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the conflict verification method based on transaction lifecycle phase awareness as described in the first aspect above.

[0018] In this embodiment, transaction timing phase tracking data of a target transaction request in the design under test is acquired. This data carries a timestamp and a phase tag corresponding to the transaction lifecycle phase. Based on the phase tag and the timestamp, a target conflict strategy is determined from a preset set of conflict strategies. This target conflict strategy corresponds to a conflict-sensitive point following the current transaction lifecycle phase. A conflict transaction request sequence is generated according to the target conflict strategy, and this sequence is sent to the design under test for verification. By sensing the transaction execution timing phase and predicting subsequent conflict-sensitive points, a conflict transaction request sequence can be generated in a targeted manner. This solves the problem of difficulty in covering complex competition boundary scenarios and improves the verification coverage of conflict scenarios. Simultaneously, the dynamic decision-making mechanism based on real-time phase tracking avoids exhaustive state space search and generates effective test sequences without frequent constraint adjustments. This overcomes the problems of test space explosion and constraint loss of effective sequences, thereby significantly improving verification efficiency and convergence speed.

[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0020] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0021] Figure 1 A flowchart illustrating a conflict verification method based on transaction lifecycle phase awareness provided in this disclosure embodiment;

[0022] Figure 2 A flowchart illustrating another conflict verification method based on transaction lifecycle phase awareness provided in this disclosure embodiment;

[0023] Figure 3 A schematic diagram of a verification framework provided in an embodiment of this disclosure;

[0024] Figure 4 A phase and monitoring diagram provided for an embodiment of this disclosure;

[0025] Figure 5 This is a schematic diagram of a conflict verification device based on transaction lifecycle phase awareness, provided in an embodiment of this disclosure. Detailed Implementation

[0026] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0027] The following description, with reference to the accompanying drawings, outlines a conflict verification method, apparatus, and device based on transaction lifecycle phase awareness, according to embodiments of this disclosure.

[0028] Figure 1 This is a flowchart illustrating a conflict verification method based on transaction lifecycle phase awareness provided in an embodiment of this disclosure. The executing entity of this method can be a server, such as a single server or a server cluster. Figure 1 As shown, the method includes the following steps:

[0029] Step 101: Obtain the transaction timing phase tracking data of the target transaction request in the design under test.

[0030] Among them, the transaction timing phase tracking data carries a timestamp and a phase label corresponding to the phase of the transaction's lifecycle.

[0031] In this embodiment of the disclosure, in a verification environment, a monitoring mechanism distributed across key nodes of the design under test can capture the timing information of target transaction requests during execution, i.e., transaction timing phase tracking data. This transaction timing phase tracking data can include at least two core elements: a timestamp and a phase tag. The timestamp records the specific time the transaction arrives at each monitoring point, while the phase tag identifies the current transaction lifecycle phase (lifecycle phase). The transaction lifecycle phase refers to the execution stages experienced by the transaction request from initiation to completion, including, for example, initiation phase, transmission phase, initial phase, processing phase, listening phase, listening and processing phase, response phase, and completion phase. The transaction lifecycle phase reflects the complete execution trajectory of the transaction from initiation to completion, providing real-time decision-making basis for subsequent conflict strategy selection.

[0032] Step 102: Determine the target conflict strategy from the preset conflict strategy set based on the phase tag and timestamp.

[0033] Among them, the target conflict strategy corresponds to the conflict-sensitive point after the current transaction lifecycle phase.

[0034] In this embodiment of the disclosure, after obtaining the phase tag and timestamp, the current lifecycle phase of the target transaction request can be identified, and potential conflict-sensitive points in the subsequent phase can be predicted. Then, a target conflict strategy can be selected from a preset set of conflict strategies. For example, conflict-sensitive points can be critical locations in subsequent stages of the transaction lifecycle phase that may lead to design flaws due to resource contention, state interference, or timing overlap. These could include competition relationships such as interconnection network resource capacity, network link transmission and routing arbitration, node processing and retransmission resources, directory maintenance state machine, cache state machine and listening response, response and directory maintenance ordering, data and state consistency, and resource allocation and release. The conflict strategy set can be a predefined set of conflict injection rules for different conflict-sensitive points. For example, it may include: a resource full-load strategy, targeting the initial local resource capacity of the interconnected network after the initiating phase; a path congestion strategy, targeting congestion of network link transmission and routing arbitrators after the transmission phase; a node congestion strategy, targeting the conflict of request and retransmission resources that nodes can handle after the initial phase; a state contention strategy, targeting the conflict of state machine competition in the subsequent directory maintenance phase; a listening interference strategy, targeting the conflict of listening to the cached state machine and listening responses after the listening phase; a state interference strategy, targeting the conflict of listening responses and directory maintenance ordering after the listening phase; a data pollution strategy, targeting the conflict of data and state consistency corruption after the response phase; and a timing interference strategy, targeting the conflict of resource management logic allocation and release competition after the completion phase. The target conflict strategy can be a specific conflict injection rule selected from the conflict strategy set based on the current transaction lifecycle phase and its subsequent conflict-sensitive points, defining the generation constraints and competition targets of conflict transaction requests.

[0035] Step 103: Generate a conflict transaction request sequence according to the target conflict strategy, and send the conflict transaction request sequence to the design under test for verification.

[0036] In this embodiment, after determining the target conflict strategy, a sequence of conflicting transaction requests conforming to the policy constraints of the target conflict strategy can be generated and sent to the design under test (DUT) for verification. For example, the sequence of conflicting transaction requests can be one or more transaction requests generated according to the constraint rules of the target conflict strategy. The address space, transaction type, and sending sequence of the conflicting transaction request sequence are specifically configured to create resource contention or state interference at subsequent conflict-sensitive points of the target transaction requests. The DUT can be a system-on-a-chip employing a multi-core consistency interconnect protocol and can include master and slave nodes connected via an interconnect network for executing transaction requests and maintaining multi-core data consistency. Sending the generated sequence of conflicting transaction requests to the DUT allows for verification of the functional correctness and stability of the DUT under conflict scenarios through actual execution.

[0037] In this embodiment, transaction timing phase tracking data of a target transaction request in the design under test is acquired. This data carries a timestamp and a phase tag corresponding to the transaction lifecycle phase. Based on the phase tag and the timestamp, a target conflict strategy is determined from a preset set of conflict strategies. This target conflict strategy corresponds to a conflict-sensitive point following the current transaction lifecycle phase. A conflict transaction request sequence is generated according to the target conflict strategy, and this sequence is sent to the design under test for verification. By sensing the transaction execution timing phase and predicting subsequent conflict-sensitive points, a conflict transaction request sequence can be generated in a targeted manner. This solves the problem of difficulty in covering complex competition boundary scenarios and improves the verification coverage of conflict scenarios. Simultaneously, the dynamic decision-making mechanism based on real-time phase tracking avoids exhaustive state space search and generates effective test sequences without frequent constraint adjustments. This overcomes the problems of test space explosion and constraint loss of effective sequences, thereby significantly improving verification efficiency and convergence speed.

[0038] In some possible implementations, the transaction lifecycle phase includes at least one of the following: initiation phase, transmission phase, initial phase, processing phase, listening phase, listening and processing phase, response phase, and completion phase;

[0039] Conflict-sensitive points include at least one of the following: initial local resource capacity of interconnected networks, network link transmission and routing arbitrator congestion, node-handled request and retransmission resources, directory maintenance state machine competition, cache state machine and listener response interference, listener response and directory maintenance ordering, data and state consistency violation, and resource management logic allocation and release competition.

[0040] The set of conflict strategies includes at least one of the following: a resource full load strategy corresponding to the initiation phase; a path congestion strategy corresponding to the transmission phase; a node congestion strategy corresponding to the initial phase; a state contention strategy corresponding to the processing phase; a listening interference strategy corresponding to the listening phase; a state interference strategy corresponding to the listening and processing phase; a data pollution strategy corresponding to the response phase; and a timing interference strategy corresponding to the completion phase.

[0041] In this embodiment, the transaction lifecycle phase includes at least one of the following: Initiation Phase (PH0): The transaction request is issued from the request engine, but has not yet entered the interconnection network of the design under test (DUT), and is awaiting confirmation. This phase begins when the REQ (Request) channel's "flit valid" signal is valid. Transmission Phase (PH1): After the transaction request is confirmed by the DUT, it is routed and transmitted in the interconnection network, but has not yet reached the target node. This phase begins when the REQ channel's "flit credit" signal is valid. Initial Phase (PH2): The transaction request arrives at the target node, but has not yet entered the core processing module, and may be cached due to node processing resource constraints. This phase begins when the master node's port REQ channel receiving module's "flit valid" signal is valid. Processing Phase (PH3): The transaction request enters the core processing module, reads the local cache directory, and performs consistency maintenance based on the directory information. It has not yet initiated consistency operations and responses for the current transaction request. This phase begins when the transaction packet enters the master node's core processing module. Listening Phase (PH4): The phase in which a transaction request triggers listening requests from one or more related cache nodes, but no listening response has yet been received. This phase begins when the "flit valid" signal of the SNP (Snoop) channel becomes valid. Listening Processing Phase (PH5): The phase in which a complete listening response has been received, but local directory maintenance has not yet been performed. This phase begins when the "flit valid" signal of the response transaction packet with the same ID (Identifier) ​​as the listening request in the SRSP (Snoop Response) or WDAT (Write Data) channel becomes valid. Response Phase (PH6): The phase in which transaction request processing is about to complete and is returning a response or data, but the response or data has not yet reached the original request node. This phase begins when the "flit valid" signal of the response transaction packet with the same ID as the primary request in the CRSP (Command Response) or RDAT (Read Data) channel becomes valid. Completion Phase (PH7): The phase in which the requesting node receives the completion response to the transaction request, performs a local state update, and releases the resources occupied by the local transaction. The starting point of this phase is the moment when the flit valid signal of the response transaction packet with the same ID as the main request in the SRSP channel becomes valid.

[0042] Conflict-sensitive points include at least one of the following: Initial local resource capacity of the interconnection network: This refers to the credit resource capacity of the interconnection network used to receive transaction requests in the initiating phase. Insufficient resources will lead to request blocking or deadlock. Network link transmission and routing arbitrator congestion: This refers to the high load state of shared links in the transmission phase and the competition for processing logic of multiple transaction priorities among arbitrator nodes. Node processing request and retransmission resources: This refers to the maximum number of requests that the target node can process simultaneously and the maximum number of retransmission request tasks that can be executed in the initial phase. Directory maintenance state machine competition: This refers to the competition for processing logic of the same address or consecutive groups of addresses in the directory state machine in the processing phase. Cache state machine and listener response interference: This refers to the conflict relationship between concurrent access to the cache state machine by multiple listener requests and multiple listener responses in the listener phase. Listener response and directory maintenance ordering: This refers to the matching relationship between the receiving order of multiple listener responses and the execution order of directory maintenance in the listener processing phase, as well as the sensitive time window for cache lines to switch from protected to unprotected states. Data and state consistency violation: This refers to the risk to data integrity in the response phase when the atomicity of transactions has not yet been finalized during data or response transmission over the network. Resource management logic allocation and release competition relationship: refers to the competition state between the time interval between the resource release moment in the completion phase and the resource allocation request of a new transaction.

[0043] The conflict strategy set includes at least one of the following, and each strategy corresponds to a phase of the transaction lifecycle: Resource Overload Strategy (P0): Corresponds to the initiation phase, continuously and rapidly sending requests to consume interconnection network credit resources, detecting credit resource allocation problems and potential deadlock scenarios. Path Congestion Strategy (P1): Corresponds to the transmission phase, controlling the address space to make a large number of transaction packets use shared links for transmission and injecting high-priority traffic, detecting arbitration logic defects. Node Congestion Strategy (P2): Corresponds to the initial phase, controlling the address space or target node sequence number to make transaction requests point to the same node, detecting request execution order and retransmission logic defects. State Contention Strategy (P3): Corresponds to the processing phase, setting access sequences for the same address or consecutive groups of addresses to test directory state robustness. Listening Interference Strategy (P4): Corresponds to the listening phase, initiating access to the same cache line as the listening request, testing the cache state machine's contention handling capability. State Interference Strategy (P5): Corresponds to the listening processing phase, selecting the same cache line as the listening request for access, testing directory maintenance robustness and state correctness during sensitive time windows. Data pollution strategy (P6): Corresponding to the response phase, this strategy tests data integrity, data merging logic, and response order logic by writing conflicting data to the target address that is currently responding. Timing interference strategy (P7): Corresponding to the completion phase, this strategy tests the correctness of resource reallocation and transaction completion sequence by creating a time interval competition between resource release and reallocation by constraining addresses pointing to the current node.

[0044] In this way, by subdividing the transaction lifecycle into eight specific phases and establishing a one-to-one correspondence between the phases and conflict-sensitive points and conflict strategies, it is possible not only to achieve accurate coverage of the entire lifecycle competition scenario of the multi-core consistency interconnection protocol, but also to clarify the specific monitoring points of each phase and the targeted detection targets of each strategy. This allows verification personnel to select the corresponding phase-strategy combination based on the specific risk points of the design under test, thereby effectively improving the accuracy of conflict injection and verification efficiency, while reducing the configuration complexity of the verification platform.

[0045] In some possible implementations, a target conflict strategy is determined from a preset set of conflict strategies based on phase tags and timestamps, including:

[0046] Obtain the execution result data of each candidate conflict strategy in historical verification;

[0047] The current verification stage is determined based on the execution result data; the verification stage includes at least one of the following: initial verification stage, mid-stage verification stage, and late verification stage.

[0048] Based on the current verification stage and execution result data, a target conflict strategy is selected from the preset conflict strategy set. The current verification stage includes the preset early verification stage, early-mid verification stage, or late verification stage, which correspond to the general decision type, the high-error decision type, and the low-performance decision type, respectively.

[0049] In this embodiment of the disclosure, when determining the target conflict strategy from a preset set of conflict strategies based on phase tags and timestamps, the execution result data of each candidate conflict strategy in historical verification can be obtained first. For example, execution feedback information of each conflict strategy in previous verification processes can be collected and stored, such as whether the strategy successfully triggered a conflict scenario, the type and number of activated design defects, and the degree of system resource blockage caused. This execution result data can be used to evaluate the effectiveness of each strategy and provide a quantitative basis for subsequent strategy selection. Then, based on the progress of historical verification and the statistical characteristics of the execution result data, the current stage of verification work can be identified, and the current verification stage can be determined. For example, the verification stage includes at least one of the following: Initial verification stage: the joint debugging stage of the verification platform and the design under test, at which time the defect distribution and phase-strategy correspondence of the design under test are not yet fully understood; Early-mid verification stage: the stage where major design defects have been initially exposed and deep defects need to be activated in a concentrated manner; Late verification stage: the stage where major defects have been repaired and the focus is on optimizing system performance and resource allocation. It is understood that each verification stage can be pre-defined, such as being determined comprehensively based on the verification objective and historical execution result data.

[0050] Subsequently, a target conflict strategy can be selected from a pre-set set of conflict strategies based on the current verification stage and execution result data. For example, the decision type can be determined by combining the characteristics of the current verification stage and historical execution result data, and the target conflict strategy can be selected according to the corresponding decision type. Decision types can include: general decision type: corresponding to the early stage of verification, conflict strategies can be selected based on both the current and subsequent phases, allowing for sufficient training on phase and conflict strategy selection to establish basic data on strategy effectiveness; high-error decision type: corresponding to the early to mid-stages of verification, a high proportion of conflict strategies that have historically successfully activated design defects are selected, focusing on detecting deep defects; low-performance decision type: corresponding to the later stage of verification, conflict strategies that cause blocking, resource constraints, and performance degradation are selected, focusing on system performance and node resource hardware allocation issues. Through the correspondence between the current verification stage and the decision type, and the quantitative feedback of execution result data on strategy effectiveness, adaptive optimization of conflict strategy selection can be achieved. Thus, by introducing a feedback mechanism of historical execution result data and decision types adapted to the verification stage, conflict strategy selection can be transformed from static pre-setting to dynamic optimization, significantly improving verification convergence speed, reducing the cost of manual intervention in adjusting strategies, and increasing verification efficiency.

[0051] In some possible implementations, acquiring transaction timing phase tracking data of the target transaction request in the design under test includes:

[0052] The effective signals of each interconnect channel are sampled by probes distributed at multiple preset phase points of the design under test;

[0053] In response to the detection of a valid signal, the current running time is recorded as a timestamp, and a corresponding phase tag is generated according to the preset phase point;

[0054] In response to the signal indicating that the internal functional resources of the master node have been completed and released, the corresponding timestamp is recorded and an end phase tag is generated;

[0055] By associating the timestamps, phase tags, and transaction identifiers of the same transaction request at different phase points, transaction time-series phase tracking data is generated.

[0056] In this embodiment of the disclosure, when acquiring transaction timing phase tracking data of a target transaction request in the design under test (DUT), probes distributed at multiple preset phase points in the DUT can first be used to sample the valid signals of each interconnect channel. For example, multiple monitoring points (probes) deployed in the DUT can be used to detect signals for different interconnect channels. Interconnect channels may include REQ channels, CRSP channels, WDAT channels, RDAT channels, SRSP channels, and SNP channels, etc. Valid signals may include flit valid signals and flit credit signals, etc., which can be used to identify the validity of channel data and the availability of credit resources, respectively. Then, in response to the detection of a valid signal, the current running time is recorded as a timestamp, and a corresponding phase label is generated based on the preset phase point. For example, when a probe detects a valid signal in an interconnect channel, the current simulation running time can be recorded as a timestamp, and a corresponding phase label can be generated based on the transaction lifecycle stage corresponding to the preset phase point. Phase tags can include, for example, PH0 (initiation phase), PH1 (transmission phase), PH2 (initial phase), PH3 (processing phase), PH4 (listening phase), PH5 (listening and processing phase), PH6 (response phase), and PH7 (completion phase), each corresponding to the start time of a transaction in different execution phases. In response to a signal indicating the completion and release of internal functional resources within the master node, a corresponding timestamp can be recorded and an end phase tag generated. For example, when the probe detects a signal indicating the completion and release of the last functional resource in the master node's internal functional module, the current running time is recorded as a timestamp, and an end phase tag PHEND (Phase End) is generated. This tag signifies that the transaction request has been fully executed and all occupied resources have been released. Subsequently, the timestamps, phase tags, and transaction identifiers of the same transaction request at different phase points can be associated to generate transaction timing phase tracking data. For example, the timestamps and phase tags generated by the same transaction request at each phase point can be associated using the transaction identifier to form complete transaction timing phase tracking data. The transaction identifier can be used to uniquely identify a transaction request, ensuring that data sampled at different monitoring points can be accurately attributed to the same transaction, thereby constructing a complete time-series trajectory of the transaction from initiation to completion.

[0057] Thus, through the distributed probe and transaction identifier association mechanism, precise monitoring and data collection throughout the entire lifecycle of transaction requests can be achieved, ensuring the accuracy and integrity of time-series data. Simultaneously, the association function of transaction identifiers can resolve the data ownership issue when multiple transactions are executed concurrently, providing a reliable data foundation for the accurate selection of subsequent conflict strategies. This significantly improves the accuracy of phase tracing and the timeliness of conflict injection.

[0058] In some possible implementations, after sending the distributed conflict transaction request sequence to the design under test for verification, the method further includes:

[0059] The detected end phase tags generated by the design under test for the target transaction requests are obtained, as well as the end timestamps corresponding to the end phase tags and the timestamps of each conflicting transaction request in the conflicting transaction request sequence.

[0060] In response to the activation of the collision calculation function by distributing the phase labels at the end;

[0061] Based on the timestamps distributed in the target transaction request, distributed in the timestamp, distributed in the end timestamp, and distributed in the sequence of conflicting transaction requests, the execution timing relationship of the conflicting transaction requests relative to each phase of the target transaction request is determined.

[0062] Based on the distribution of execution timing relationships and the conflict-sensitive phases corresponding to the target conflict strategy, it is determined whether the target conflict strategy successfully triggers the conflict scenario distributed in the design under test.

[0063] In this embodiment of the disclosure, after the conflict transaction request sequence is sent to the design under test for verification, the effectiveness of the conflict strategy can be quantitatively evaluated through timestamp comparison and timing relationship analysis. For example, the end phase label generated by the design under test for the target transaction request, the end timestamp corresponding to the end phase label, and the timestamps of each conflict transaction request in the conflict transaction request sequence can be obtained. For example, after verification execution, the following information can be extracted from the transaction timing phase tracking data: the end phase label of the target transaction request and its corresponding end timestamp; the timestamps of each conflict transaction request in the conflict transaction request sequence at each phase point; the end timestamp marking the end time of the target transaction execution; and the timestamps of the conflict transaction requests marking the arrival time of each phase during their execution. These two constitute the basic data for timing comparison. Then, in response to the end phase label, the conflict calculation function can be activated. For example, when the end phase label of the target transaction request is detected, the execution of the conflict calculation function can be triggered. The activation mechanism ensures that conflict determination is only performed after the target transaction has been fully executed, avoiding premature determination that leads to incomplete timing data.

[0064] Subsequently, based on the timestamps of the target transaction request, its end timestamp, and the timestamps of the conflicting transaction request sequence, the execution timing relationship of the conflicting transaction request relative to each phase of the target transaction request can be determined. For example, the timestamp sequence of the target transaction request (including each phase timestamp and the end timestamp) can be compared with the timestamps of the conflicting transaction request sequence to analyze the positional relationship of the execution time of the conflicting transaction request relative to each phase of the target transaction request. The execution timing relationship can include whether a specific phase of the conflicting transaction request falls within the critical phase interval of the target transaction request, and the degree of overlap and order between the two on the timeline. Then, based on the execution timing relationship and the conflict-sensitive phase corresponding to the target conflict strategy, it can be determined whether the target conflict strategy successfully triggers the conflict scenario of the design under test. For example, the determined execution timing relationship can be matched and verified with the conflict-sensitive phase targeted by the target conflict strategy. If the execution timing of the conflicting transaction request falls within the predetermined conflict-sensitive phase interval of the target conflict strategy, the conflict strategy is deemed to have successfully triggered the conflict scenario; otherwise, it is deemed not to have successfully triggered it. This determination result is used to evaluate the effectiveness of the conflict strategy. Thus, by ending the phase tag activation mechanism and the temporal relationship quantification analysis, the effectiveness of the conflict strategy can be automatically determined, thereby significantly improving the automation level and accuracy of the verification process.

[0065] In some possible implementations, the method further includes:

[0066] In response to the determination that the target conflict strategy has successfully triggered a conflict scenario, the selection weight value of the target conflict strategy under the current transaction lifecycle phase is increased;

[0067] In response to the determination that the target conflict strategy has failed to trigger a conflict scenario, the selection weight value of the target conflict strategy in the current transaction lifecycle phase is reduced.

[0068] In this embodiment, the probability of strategy selection can be optimized through dynamic feedback to achieve adaptive learning of the conflict strategy. For example, when the determination result is a successful triggering of a conflict scenario, the selection weight value of the target conflict strategy under its corresponding transaction lifecycle phase can be increased. The increase in weight value can be determined based on factors such as the number of historical successes and the severity of defects, giving the strategy a higher probability of being selected in subsequent strategy selections at the same phase. When the determination result is a failure to trigger a conflict scenario, the selection weight value of the target conflict strategy under its corresponding transaction lifecycle phase can be decreased. The decrease in weight value can be determined based on factors such as the number of historical failures and resource consumption, avoiding repeated selection of invalid strategies and optimizing the allocation efficiency of verification resources. The selection weight value can be a quantitative indicator of the probability of selection of each candidate conflict strategy relative to a specific transaction lifecycle phase during the conflict strategy selection process. The level of the weight value directly affects the policy selector's preference for that strategy; a higher weight value results in a greater probability of selection. Thus, by introducing a dynamic adjustment mechanism for the selection weight value, the conflict strategy selection can possess self-learning and optimization capabilities, thereby significantly improving verification efficiency and defect detection rate while reducing the cost of manual intervention in strategy adjustment.

[0069] In some possible implementations, after acquiring the transaction timing phase tracking data of the target transaction request in the design under test, the method further includes:

[0070] Store the transaction timing phase tracking data into a preset data packet buffer and update the conflict count corresponding to the target transaction request;

[0071] In response to the detection that the transaction timing phase tracking data contains an end phase tag indicating the completion of execution, and that the conflict counter corresponding to the target transaction request is not zero, the transaction timing phase tracking data is synchronized to the preset conflict counter, and the corresponding resources in the data packet buffer are released.

[0072] In this embodiment of the disclosure, after acquiring the transaction timing phase tracking data of the target transaction request in the design under test, efficient storage of verification data and on-demand activation of conflict calculation can be achieved through the synergistic effect of the data packet buffer and the conflict counter. For example, after acquiring the transaction timing phase tracking data, the data can be stored in a preset data packet buffer for temporary storage of timing tracking information during transaction execution; simultaneously, the conflict counter corresponding to the target transaction request can be updated to record the cumulative number of times the transaction has been selected as a conflict-generating target. The conflict counter can be used to identify the frequency with which the current transaction is selected by the strategy selector for conflict injection during the verification process. The data packet buffer can be a storage area in the verification environment used to cache transaction timing phase tracking data, with a preset capacity. When new data enters, if the data packet buffer is full, it is overwritten according to the order of data caching; when data containing an end phase tag is detected and the conflict counter corresponding to the data is not zero, the data is synchronized to the conflict calculator and resources are released. The conflict counter can be a counter associated with a specific transaction request, used to record the number of times the transaction is selected as a conflict target. The counter increments each time the policy selector selects the transaction to generate a sequence of conflicting transaction requests.

[0073] Data synchronization and resource release are triggered when the following two conditions are met: the transaction time-series phase tracking data contains an end-phase tag, indicating that the transaction has been completed; and the conflict counter corresponding to the transaction is not zero, indicating that the transaction was selected as a conflict target. After these two conditions are met, the complete time-series phase tracking data can be synchronized to the conflict calculator for conflict result determination and analysis. Simultaneously, the storage resources occupied by the transaction in the data packet buffer can be released for subsequent data use. The conflict calculator can be a functional module in the verification environment used to perform conflict result determination. It receives complete time-series data from the data packet buffer and, based on timestamp comparison and time-series relationship analysis, determines whether the conflict strategy has successfully triggered a conflict scenario. Thus, through the temporary storage of the data packet buffer and the conditional filtering of the conflict counter, efficient management of verification data and precise activation of conflict calculations can be achieved, thereby reducing the storage pressure and computational load of the verification system and improving the scalability and operational efficiency of the verification platform.

[0074] In some possible implementations, the method further includes:

[0075] The target transaction request and the sequence of conflicting transaction requests are sent synchronously to the preset reference model;

[0076] Obtain the execution results of the design under test and the processing results of the reference model;

[0077] Compare the execution results with the processing results, and generate and output error feedback information based on the differences.

[0078] In this embodiment, the correctness of the design under test (DUT) can be automatically verified through parallel simulation and result comparison using a reference model. For example, when sending the target transaction request and conflicting transaction request sequences to the DUT, the same request sequence can be synchronously sent to a preset reference model. The reference model can be an abstract model used in the verification environment to simulate the expected behavior of the DUT. Its function is consistent with the DUT but does not contain specific implementation details, and it is used to generate theoretically correct processing results as a comparison benchmark. Then, the execution results generated by the DUT after actually executing the target transaction request and conflicting transaction request sequences, as well as the processing results generated by the reference model under the same input conditions, can be collected. The execution results and processing results can include information such as transaction responses, data content, status updates, and completion order. Afterward, the execution results of the DUT can be compared item by item with the processing results of the reference model. If inconsistencies exist, it is determined to be a functional error, and error feedback information is generated and output. The error feedback information can include detailed information such as the type of difference, the identifier of the involved transaction, the time of occurrence, and the expected and actual values, to guide designers in locating and fixing defects. Thus, by introducing a parallel simulation mechanism based on a reference model, the correctness of the design under test can be automatically determined, thereby providing an objective standard for correctness evaluation and avoiding the tediousness and subjectivity of manual inspection results. At the same time, the structured output of error feedback information can shorten the defect location time and improve verification efficiency and debugging convenience.

[0079] To make the methods provided in this disclosure clearer, the following examples will be used for illustration.

[0080] Figure 2 This disclosure provides a conflict verification method based on transaction lifecycle phase awareness, such as... Figure 2 As shown, the conflict verification method based on transaction lifecycle phase awareness includes the following processing:

[0081] 1. By analyzing transaction types, protocol characteristics, and system microarchitecture features, we identify the transaction lifecycle phases with high conflict sensitivity from initiation to completion, and the corresponding conflict-sensitive points within each phase. Details are as follows:

[0082] Initiation Phase: The transaction request is issued from the request engine, but it has not yet entered the interconnection network of the design under test and needs to wait for confirmation. The conflict sensitivity point corresponding to the initiation phase is the initial local resource capacity of the interconnection network.

[0083] Transmission phase: When the design under test (DUT) returns an acknowledgment that a transaction request has been received, the transaction request will be routed through the DUT's network, but has not yet reached the target node. The conflict-sensitive points corresponding to this transmission phase are network link transmission and routing arbitrator congestion.

[0084] Initial phase: The transaction request is received by the target node, but has not yet entered the transaction processing phase. In most designs, the transaction request may be cached due to the current node's limited processing resources. The conflict-sensitive points in the initial phase are node cached resources, resources available for processing requests, and resources for request retransmission.

[0085] Processing Phase: Transaction requests begin processing, the local cache directory is read, and consistency maintenance is performed based on the directory information. Consistency operations and responses for the current transaction request have not yet been initiated. The conflict-sensitive point in the processing phase is the contention between the directory maintenance state machine and other components.

[0086] Listening Phase: A transaction request triggers listening requests from one or more related cache nodes, but no listening response has yet been received for the current listening request. The conflict sensitivity point of the listening phase is the conflict between cache state machine interference and multiple listening responses.

[0087] Listening and processing phase: A complete listening response has been received, but local directory maintenance has not yet been performed. The conflict sensitivity point of the listening and processing phase is the order of listening responses versus the order of directory maintenance.

[0088] Response Phase: The transaction request is about to complete and is returning a response or data, but the response or data has not yet reached the original requesting node. Conflict sensitivities in the response phase include data inconsistency, state inconsistency, and disordered response ordering.

[0089] Completion Phase: Upon receiving the completion response to the transaction request, the requesting node performs a local state update and releases the resources occupied by the local transaction. The conflict sensitivity point of the completion phase is the competition between resource allocation and release in the resource management logic.

[0090] 2. By analyzing the conflict-sensitive points of the transaction lifecycle phases, corresponding conflict strategies are formulated. The random attributes and ranges of transaction requests under the conflict strategy are defined to generate request sequences, as well as the error types that may be triggered under this conflict strategy. Specifically:

[0091] For the initiating phase, the conflict sensitivity point is the initial local resource capacity of the interconnection network, and the key point is whether the interconnection network's credit resources are sufficient. Based on this key point, a resource full-load strategy is formulated. In this case, random variables such as transaction type and address space can be randomized, and a continuous and rapid sending of requests is used to consume the interconnection network's credit resources. This conflict strategy can detect credit resource allocation problems and potential deadlock scenarios.

[0092] For transmission phases, the conflict-sensitive points are network link transmission and routing arbitrator congestion. The key points are the target transaction's shared link transmission and the arbitrator node's handling logic regarding transaction priorities. Based on these key points, a path congestion strategy is formulated. In this case, the transaction type can be randomized, and by controlling the address space, a large number of transaction packets can use shared link transmission. High-priority traffic can be injected by adjusting the QoS field in the request packet. This conflict strategy can detect defects in the arbitration logic.

[0093] For the initial phase, the conflict-sensitive points are the node's processable request resources and request retransmission resources. The key points are the maximum number of requests the current node can handle and the maximum number of retransmission request tasks it can execute. Based on these key points, a node congestion strategy is formulated. In this case, the transaction type can be random, but control over the address space or target node sequence number is needed to ensure that the endpoints of transaction requests point to the same node. This conflict strategy can detect issues with the execution order of requests and defects in the request retransmission logic.

[0094] For phase handling, the conflict-sensitive point is the competition relationship in the directory maintenance state machine. The key point lies in the processing logic of the same address or multiple consecutive identical group addresses in the directory state machine. Based on this key point, a state competition strategy is formulated. At this time, the transaction type can be selectively randomized, such as continuous reads or continuous writes; the address space can be set with the same address or a sequence of consecutive identical group addresses. This conflict strategy can be used to test the robustness of the directory state.

[0095] For the listener phase, the conflict-sensitive points are interference from the cache state machine and interference from multiple listener responses. The key point lies in the address protection and state protection of the same cache line while the transaction is waiting for the listener response. Based on this key point, a listener interference strategy is formulated. In this case, the transaction type can be random, but the address must be selected from the same cache line as the listener request. This conflict strategy can test whether the maintenance of cache lines violates consistency under conflict conditions.

[0096] For the listening processing phase, the conflict sensitivity point is the order of listening responses versus the order of directory maintenance. The key issue lies in receiving responses to multiple listening requests, conflicts arising during directory maintenance, and the sensitive time window involving cache lines switching from protected to unprotected states. Based on this key point, a state interference strategy is developed. In this strategy, the transaction type can be randomized, but the address must be the same cache line as the listening request. This conflict strategy can test the robustness of directory maintenance and the state correctness of conflicting transactions within the sensitive time window.

[0097] For the response phase, conflict sensitivities include data consistency violations, state consistency violations, and response ordering disruptions. The key point is that data or responses are in the process of network transmission, and transaction atomicity has not yet been definitively determined. Based on this key point, a data pollution strategy is formulated. In this case, the transaction type is selected as a write request, the address points to the target address currently receiving the response, and conflicting data is written. This conflict strategy can test data integrity, data merging logic, and response ordering logic.

[0098] For the completion phase, the conflict sensitivity point is the competition between resource allocation and release in resource management logic. The key is predicting the resource release time point, as a new transaction is about to use the resource, creating a competition state between the resource release and re-allocation time interval. A timing interference strategy is formulated, where the transaction type is randomized and the address is constrained to point to the current node. This conflict strategy can test resource reallocation and the correctness of the transaction completion sequence under competition.

[0099] 3. Add corresponding monitoring components to the verification environment to capture the current phase of the transaction request, combine them into a transaction timing phase tracking data stream carrying timestamps and phase tags, and provide it to the conflict policy selector.

[0100] 4. The conflict strategy selector selects the best conflict opportunity based on the phase label and timestamp, providing the decision strategy to the incentive generator. The conflict strategy selector learns and optimizes decisions based on historical injection effects, and the decisions are divided into three types:

[0101] General decision type: Both conflict strategies corresponding to the current phase and conflict strategies after the current phase can be selected. Suitable for the initial stage of verification platform and joint debugging with the design under test, to fully train the selection of phase and conflict strategy.

[0102] High-error decision type: This type involves a high weighting of choices based on conflicting strategies that leverage historically successfully activated design flaws. Suitable for the early to mid-stages of validation, it will detect a large number of design flaws.

[0103] Low-performance decision type: Conflict injection causes blocking, resource shortages, and ultimately performance degradation. Suitable for the later stages of verification, after many defects have been fixed, when the focus shifts to system performance and node resource hardware allocation.

[0104] Using different types of decisions at different verification stages can achieve twice the result with half the effort, and the verification convergence speed can be improved rapidly.

[0105] 5. The stimulus generator, based on the received conflict strategy decision, generates a sequence of transaction requests that conforms to the random constraints of that conflict strategy. The generated request sequence packets conform to the protocol specification and design specification. The generator marks the initiation phase and records the sending timestamp of the transaction request sequence packets before sending them to the design under test.

[0106] As a concrete example, Figure 3 This is a schematic diagram of a verification framework for a specific embodiment provided in this disclosure. For example... Figure 3 As shown, Figure 3 The area within the dashed lines represents the Design Under Test (DUT), a multi-core consistent interconnect structure. The consistent interconnect bus uses the AMBA (Advanced Microcontroller Bus Architecture) and CHI (Coherent Hub Interface) bus protocols for interconnection. A ring routing structure connects the verification environment to the eight master nodes and one slave node of the DUT. The DUT maintains multi-core consistency through the master nodes, and its interfaces with the verification environment also use the CHI bus protocol. The verification environment mainly includes the following components: a request engine component, an intelligent conflict component, a monitoring component, a model component, a comparison component, and a memory component.

[0107] The main functions implemented by each component in the verification environment are as follows:

[0108] Request Engine Component: Generates requests based on the strategy guidance of the Intelligent Conflict Component and sends the requests to the design under test; at the same time, it also sends the generated requests to the Model Component.

[0109] Intelligent conflict component: Based on the transaction lifecycle phase, it selects the appropriate conflict strategy and adjusts the conflict strategy and scope according to the transaction execution process information provided by the monitoring component. The adjustment results are then notified to the request engine component.

[0110] Monitoring Component: Monitors the transaction execution process and results of the design under test, sends the results to the comparison component, provides the monitored transaction execution process to the model component for processing point identification, and provides the transaction execution process to the intelligent conflict component.

[0111] Model component: Simulates the behavior of the design under test and processes the requests provided by the request engine, sending the processing results to the comparison component; at the same time, it can synchronize the processing time points of the model component and the design under test based on the information provided by the monitoring component.

[0112] Comparison component: Compares the information transmitted by the monitoring component and the model component, and provides feedback on error information.

[0113] Memory component: Allocates memory space and initializes data used in the verification environment.

[0114] The phase monitoring method is as follows:

[0115] By combining the consistency protocol and system architecture, when building the verification platform, distributed probes are used to sample phase points, which can obtain a transaction time-series phase tracking data packet carrying timestamps and phase tags.

[0116] The CHI protocol port contains six channels: REQ, CRSP, WDAT, RDAT, SRSP, and SNP. An example diagram is shown below. Figure 4 As shown, the request engine component initiates a transaction request in the REQ channel. The specific sampling method, timestamp, and phase label relationship of the transaction timing phase tracking data packet are as follows:

[0117] At time T0, initiate the phase start point, send a main request, the probe detects the valid signal of the REQ channel at the route channel ingress, and records the current running time T0 and the phase tag PH0;

[0118] At time T1, the transmission phase begins, credit feedback information appears at the routing channel inlet, the probe detects the valid signal of the REQ channel flit credit at the routing channel inlet, and records the current running time T1 and phase tag PH1;

[0119] At time T2, the initial phase start point, the main request arrives at the master node, the probe detects that the REQ channel receiving module on the master node port is flit valid, and records the current running time T2 and phase tag PH2;

[0120] At time T3, the processing phase begins. The main request enters the core processing module. The probe detects that the master node has started processing the transaction packet. The start of processing is marked as the transaction packet enters the master node's core processing module. The cache module for the transaction packet inside the master node is not part of the core processing module. The current running time T3 and phase tag PH3 are recorded.

[0121] At time T4, the listening phase starts. The listening request initiated by the master request is sent. The probe detects the flit valid signal of the master node's SNP channel and records the current running time T4 and the phase tag PH4. If no listening request is initiated at present, the data packet does not have the current running time and the current phase tag.

[0122] At time T5, the monitoring process starts at the phase start point, verifies the environment's response to the monitoring request, and the probe detects the flit valid signal of the response transaction packet with the same SNP channel request ID as the SRSP channel or WDAT channel at the routing channel ingress. The current running time T5 and phase tag PH4 are recorded. If there are no T4 and PH4 tags, then there are no T5 and PH5 tags at this time.

[0123] At time T6, the starting point of the response phase, the master node responds to the master request. The probe detects the response transaction packet with the same ID as the master request in the master node's CRSP channel or RDAT channel, and records the current running time T6 and the phase tag PH6.

[0124] At time T7, the phase start point is completed, the response of the main request arrives at the verification environment, the verification environment returns a completion response to the main request, the probe detects the flitvalid valid signal of the response transaction packet with the same ID as the main request in the SRSP channel of the routing channel entry, and records the current running time T7 and phase tag PH7.

[0125] At time point T8, the phase completion endpoint is reached, and the corresponding packet arrives at the master node. The probe detects the signal indicating that the last functional resource of the internal functional module of the master node has been executed and released, and records the current runtime T8 and the phase tag PHEND. At this point, a complete record of a transaction timing phase tracing data packet is obtained.

[0126] Phase and monitoring diagrams can be as follows Figure 4 As shown. The intelligent collision component can contain four main functional devices: a packet buffer, a collision packet buffer, a policy selector, and a collision calculator. Among them,

[0127] Packet buffer: Responsible for buffering and managing transaction timing phase tracking data packets;

[0128] Conflict packet buffer: Responsible for buffering the address and transaction ID of conflict packets generated by the policy selector, as well as the transaction ID of the transaction timing phase clock packet used for conflict, with the purpose of identifying whether the current conflict policy has successfully caused a conflict scenario.

[0129] Strategy Selector: Responsible for maintaining the relationship between phase and conflict strategy matrices, obtaining transaction timing phase tracking data packets from the data packet buffer, and selecting conflict strategies based on the phase labels displayed in the data packets.

[0130] Conflict Calculator: Calculates conflict time, determines whether a conflict is successful, and feeds back the results to the strategy selector, providing guidance for subsequent conflict strategy selection.

[0131] A specific implementation of the intelligent conflict component is as follows:

[0132] The packet buffer capacity is set to 800; any excess packets will be overwritten in the order they were cached. Each time a new packet enters the buffer, a collision counter is incremented to indicate the number of times the current transaction has been selected to generate a collision. When a packet's tag shows PHEND, it indicates that the current transaction has completed. If the collision counter for the current packet is non-zero, the packet information is first synchronized to the collision counter, and then the packet is deleted, releasing the packet buffer resources.

[0133] The conflict packet buffer capacity is set to 300. When the conflict packet capacity reaches the limit, conflict injection is paused. The buffer matches the transaction IDs in the packet buffer. If a conflict packet with the same transaction ID is found in the packet buffer, the conflict packet is deleted, and the conflict packet buffer resources are released.

[0134] It is understood that the buffer capacity is only for illustrative purposes and is not intended as a limiting indicator.

[0135] As shown in the table below, Table 1 is a schematic diagram of the relationship matrix between the phase and conflict strategy of a strategy selector.

[0136] Table 1

[0137]

[0138] The smaller the phase number, the earlier the transaction packet processing stage, and the more conflict strategies can be selected. For example, when the transaction packet is in phase T0, any one of the eight strategies from P0 to P7 can be selected; similarly, when the transaction packet is in phase T1, any one of the seven strategies from P1 to P7 can be selected, and so on. The initial standard weight of the strategy selected by the strategy selector is set to the average selection, and the strategy selection weight value is intelligently adjusted for various phases based on the execution of conflict incentives and the data provided by the conflict calculator. A recorder is set to record the number of times the selectable conflict strategies in the current phase are selected for analysis after the simulation.

[0139] The following examples illustrate the implementation of the strategy selector.

[0140] Once the verification platform starts running, the data packet buffer receives transaction timing phase tracking data packets input by the monitoring component. If the policy selector determines that the data packet buffer capacity is not empty, it can begin operation.

[0141] The strategy selector prioritizes extracting transaction packets with a collision count of 0 from the packet buffer and parses them. For example, the currently extracted running transaction packet has a phase label of PH2. When the phase is PH2, the strategy selector can choose from six collision strategies: P2, P3, P4, P5, P6, and P7. With the same initial weight values, the current strategy selector selects the P4 monitoring and interference strategy. Based on the random constraint attribute specified by the current strategy (same address attribute), it generates a conflicting transaction packet. The address of the conflicting transaction packet equals the address of the running transaction packet. A conflicting transaction packet ID is generated, and then the conflicting transaction packet is saved to the collision packet buffer and sent to the request engine component for execution.

[0142] Simultaneously, the policy selector can package the following data and provide it to the conflict calculator: the transaction ID of the running transaction packet, the transaction ID of the conflicting transaction packet, the phase label PH2, and the conflict policy selection P4. The current data packet is named the data packet to be calculated.

[0143] The execution process of the conflict calculator:

[0144] The conflict calculator stores the data packets to be calculated and waits for a notification packet indicating the end of the PHEND phase tag with the same transaction ID as the running transaction packet to activate the calculation function.

[0145] For example, upon receiving a data packet with the PHEND keyword from the data buffer, the system searches for a packet with the same transaction ID as the running transaction packet in the currently stored computation data packet. From this computation data packet, the conflicting transaction packet's transaction ID is extracted. Using this ID, the system indexes the transaction packet with the same conflicting transaction ID from the data buffer and reads the information into the conflict calculator. After completing this process, the following information is displayed:

[0146] Data packet information with PHEND: AT0, AT1, AT2, AT3, AT4, AT5, AT6, AT7, AT8. Note that AT here represents a specific time value.

[0147] Retrieve information about transaction packets with the same transaction ID as the conflicting transaction packet: BT0, BT1, BT2, BT3. Note that BT here represents a specific time value. BT3 is the start time of the processing phase, indicating that the current transaction is still being processed.

[0148] The success of the conflict strategy is determined by calculating the time values ​​of AT and BT.

[0149] The current policy selection is P4, with a relevant time range between AT4 and AT5. If BT3 is less than AT5 and BT3 is greater than AT3, then the conflict effect of policy P4 is considered achieved. Then, the policy selector can be notified to increment the policy selection weight value corresponding to phase PH2 by 1. If it is not within the current range, then the conflict effect of policy P4 is considered not achieved. Then, the policy selector can be notified to decrement the policy selection weight value corresponding to phase PH2 by 1. When the corresponding policy selection weight value is 0, no further subtraction is performed. After successfully notifying the policy selector, the corresponding data packet to be calculated is deleted.

[0150] After the operation is completed, the strategy selector can output the corresponding end-of-operation weight value for each phase, as well as a summary of the number of times the current phase strategy was selected. For example, the output results of the PH2 phase selection input to the strategy selector are shown in Table 2 below:

[0151] Table 2

[0152]

[0153] Based on the information in Table 2 above, the following information can be obtained: When the transaction packet is in the initial phase of PH2: The node congestion strategy was selected 50 times, with 40 failures and 10 successes. The state contention strategy was selected 20 times, with all 20 failures. The eavesdropping interference strategy was selected 60 times, with all 60 successes. The state interference strategy was selected 50 times, with all 50 successes. The data pollution strategy was selected 50 times, with 10 failures and 40 successes. The timing interference strategy was selected 40 times, with all 40 failures.

[0154] By analyzing a large amount of simulation data, we can obtain the optimal conflict strategy selection weight value corresponding to the initial phase of PH2. Then, we can modify the initial weight value to optimize the strategy selector.

[0155] Similarly, the control of other phases is the same as in the current embodiment. It is understood that the values ​​in Table 2 are for illustrative purposes only and are not intended as limiting indicators.

[0156] In this way, a large number of representative competitive test sequences can be generated in the early stages of verification. As the verification process progresses, the competitive test sequences will cover more boundary scenarios, thereby reducing the cost of manual intervention and improving the verification efficiency and convergence speed of multi-core consistency systems. Moreover, triggering more competitive test sequences in the early stages can provide a reference for competitive scenarios, allowing for early prediction of subsequent functional design and performance debugging, and thus improving the overall SoC system design schedule.

[0157] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0158] According to embodiments of this disclosure, this disclosure also provides a conflict verification apparatus based on transaction lifecycle phase awareness. For example, Figure 5 This is a schematic diagram of a conflict verification device based on transaction lifecycle phase awareness, provided in an embodiment of this disclosure. The conflict verification device 500 based on transaction lifecycle phase awareness includes:

[0159] The data acquisition module 510 is used to acquire transaction timing phase tracking data of the target transaction request in the design under test; wherein, the transaction timing phase tracking data carries a timestamp and a phase tag corresponding to the phase of the transaction lifecycle;

[0160] The strategy determination module 520 is used to determine a target conflict strategy from a preset set of conflict strategies based on the phase tag and the timestamp; wherein the target conflict strategy corresponds to a conflict-sensitive point following the current transaction lifecycle phase;

[0161] The conflict verification module 530 is used to generate a conflict transaction request sequence according to the target conflict strategy, and send the conflict transaction request sequence to the design under test for verification.

[0162] Furthermore, the transaction lifecycle phase includes at least one of the following: initiation phase, transmission phase, initial phase, processing phase, listening phase, listening and processing phase, response phase, and completion phase;

[0163] The conflict-sensitive points include at least one of the following: initial local resource capacity of the interconnection network, network link transmission and routing arbitrator congestion, node-processable request and retransmission resources, directory maintenance state machine competition, cache state machine and listener response interference, listener response and directory maintenance ordering, data and state consistency violation, and resource management logic allocation and release competition.

[0164] The set of conflict strategies includes at least one of the following: a resource full load strategy corresponding to the initiation phase; a path congestion strategy corresponding to the transmission phase; a node congestion strategy corresponding to the initial phase; a state contention strategy corresponding to the processing phase; a listening interference strategy corresponding to the listening phase; a state interference strategy corresponding to the listening processing phase; a data pollution strategy corresponding to the response phase; and a timing interference strategy corresponding to the completion phase.

[0165] Furthermore, the strategy determination module 520 is used for:

[0166] Obtain the execution result data of each candidate conflict strategy in historical verification;

[0167] The current verification stage is determined based on the execution result data; wherein, the verification stage includes at least one of the following: initial verification stage, early-mid verification stage, and late verification stage.

[0168] Based on the current verification stage and the execution result data, the target conflict strategy is selected from the preset conflict strategy set; wherein, the current verification stage includes the preset early verification stage, early-mid verification stage, or late verification stage, which correspond to the general decision type, the high error decision type, and the low performance decision type, respectively.

[0169] Furthermore, the data acquisition module 510 is used for:

[0170] The effective signals of each interconnect channel are sampled by probes distributed at multiple preset phase points of the design under test;

[0171] In response to the detection of the valid signal, the current running time is recorded as the timestamp, and the corresponding phase tag is generated according to the preset phase point;

[0172] In response to the signal indicating that the internal functional resources of the master node have been completed and released, the corresponding timestamp is recorded and an end phase tag is generated;

[0173] The transaction time-series phase tracking data is generated by associating the timestamps, phase tags, and transaction identifiers of the same transaction request at different phase points.

[0174] Furthermore, it also includes a conflict resolution module, used for:

[0175] Obtain the detected end phase tag generated by the design under test for the target transaction request, the end timestamp corresponding to the end phase tag, and the timestamp of each conflicting transaction request in the conflicting transaction request sequence;

[0176] In response to the termination phase tag, the collision calculation function is activated;

[0177] Based on the timestamps of each of the target transaction requests, the end timestamp, and the timestamps of the conflicting transaction request sequence, the execution timing relationship of the conflicting transaction requests relative to each phase of the target transaction request is determined.

[0178] Based on the execution timing relationship and the conflict-sensitive phase corresponding to the target conflict strategy, determine whether the target conflict strategy successfully triggers the conflict scenario of the design under test.

[0179] Furthermore, it also includes an adjustment module for:

[0180] In response to the determination that the target conflict strategy has successfully triggered the conflict scenario, the selection weight value of the target conflict strategy in the current transaction lifecycle phase is increased;

[0181] In response to the determination that the target conflict strategy has failed to trigger the conflict scenario, the selection weight value of the target conflict strategy in the current transaction lifecycle phase is reduced.

[0182] Furthermore, it also includes:

[0183] The update module is used to store the transaction timing phase tracking data into a preset data packet buffer and update the conflict count corresponding to the target transaction request.

[0184] The resource release module is used to synchronize the transaction timing phase tracking data to a preset conflict counter and release the corresponding resources in the data packet buffer in response to detecting that the transaction timing phase tracking data contains an end phase tag indicating the completion of execution and that the conflict counter corresponding to the target transaction request is not zero.

[0185] Furthermore, it also includes a feedback module for:

[0186] The target transaction request and the conflicting transaction request sequence are simultaneously sent to a preset reference model;

[0187] Obtain the execution results of the design under test and the processing results of the reference model;

[0188] The execution result is compared with the processing result, and error feedback information is generated and output based on the comparison difference.

[0189] It should be noted that the description of the features in the embodiment of the conflict verification device based on transaction lifecycle phase awareness can be found in the relevant description of the embodiment of the conflict verification method based on transaction lifecycle phase awareness, and will not be repeated here.

[0190] Embodiments of this disclosure also provide an electronic device including a memory and a processor, the memory storing a computer program, the processor being configured to run the computer program to perform the steps in any of the above embodiments of the conflict verification method based on transaction lifecycle phase awareness.

[0191] Embodiments of this disclosure also provide a computer-readable storage medium storing a computer program configured to execute the steps in any of the above embodiments of the conflict verification method based on transaction lifecycle phase awareness.

[0192] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0193] The embodiments of this disclosure also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the conflict verification method based on transaction lifecycle phase awareness.

[0194] Embodiments of this disclosure also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the conflict verification method based on transaction lifecycle phase awareness.

[0195] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0196] The foregoing has provided a detailed description of a conflict verification method based on transaction lifecycle phase awareness. Specific examples have been used to illustrate the principles and implementation methods of this disclosure. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this disclosure without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this disclosure.

Claims

1. A conflict verification method based on transaction lifecycle phase awareness, characterized in that, include: Obtain transaction timing phase tracking data of the target transaction request in the design under test; wherein, the transaction timing phase tracking data carries a timestamp and a phase tag corresponding to the transaction lifecycle phase, and the transaction lifecycle phase includes at least one of the following: initiation phase, transmission phase, initial phase, processing phase, listening phase, listening and processing phase, response phase, and completion phase; Based on the phase tag and the timestamp, a target conflict strategy is determined from a preset conflict strategy set. The target conflict strategy corresponds to a conflict-sensitive point following the current transaction lifecycle phase. The conflict strategy set includes at least one of the following: a resource full-load strategy corresponding to the initiation phase; a path congestion strategy corresponding to the transmission phase; a node congestion strategy corresponding to the initial phase; a state contention strategy corresponding to the processing phase; a listening interference strategy corresponding to the listening phase; a state interference strategy corresponding to the listening processing phase; a data pollution strategy corresponding to the response phase; and a timing interference strategy corresponding to the completion phase. The conflict-sensitive points include at least one of the following: initial local resource capacity of the interconnection network, network link transmission and routing arbitrator congestion, node-processable request and retransmission resources, directory maintenance state machine contention, cache state machine and listening response interference, listening response and directory maintenance ordering, data and state consistency corruption, and resource management logic allocation and release contention. A conflict transaction request sequence is generated according to the target conflict strategy, and the conflict transaction request sequence is sent to the design under test for verification.

2. The conflict verification method based on transaction lifecycle phase awareness according to claim 1, characterized in that, The step of determining the target conflict strategy from a preset set of conflict strategies based on the phase tag and the timestamp includes: Obtain the execution result data of each candidate conflict strategy in historical verification; The current verification stage is determined based on the execution result data; wherein, the verification stage includes at least one of the following: initial verification stage, early-mid verification stage, and late verification stage. Based on the current verification stage and the execution result data, the target conflict strategy is selected from the preset conflict strategy set; wherein, the current verification stage includes the preset early verification stage, early-mid verification stage, or late verification stage, which correspond to the general decision type, the high error decision type, and the low performance decision type, respectively.

3. The conflict verification method based on transaction lifecycle phase awareness according to claim 1, characterized in that, The acquisition of transaction timing phase tracking data for the target transaction request in the design under test includes: The effective signals of each interconnect channel are sampled by probes distributed at multiple preset phase points of the design under test; In response to the detection of the valid signal, the current running time is recorded as the timestamp, and the corresponding phase tag is generated according to the preset phase point; In response to the signal indicating that the internal functional resources of the master node have been completed and released, the corresponding timestamp is recorded and an end phase tag is generated; The transaction time-series phase tracking data is generated by associating the timestamps, phase tags, and transaction identifiers of the same transaction request at different phase points.

4. The conflict verification method based on transaction lifecycle phase awareness according to claim 1, characterized in that, After sending the conflicting transaction request sequence to the design under test for verification, the method further includes: Obtain the detected end phase tag generated by the design under test for the target transaction request, the end timestamp corresponding to the end phase tag, and the timestamp of each conflicting transaction request in the conflicting transaction request sequence; In response to the termination phase tag, the collision calculation function is activated; Based on the timestamps of each of the target transaction requests, the end timestamp, and the timestamps of the conflicting transaction request sequence, the execution timing relationship of the conflicting transaction requests relative to each phase of the target transaction request is determined. Based on the execution timing relationship and the conflict-sensitive phase corresponding to the target conflict strategy, determine whether the target conflict strategy successfully triggers the conflict scenario of the design under test.

5. The conflict verification method based on transaction lifecycle phase awareness according to claim 4, characterized in that, The method further includes: In response to the determination that the target conflict strategy has successfully triggered the conflict scenario, the selection weight value of the target conflict strategy in the current transaction lifecycle phase is increased; In response to the determination that the target conflict strategy has failed to trigger the conflict scenario, the selection weight value of the target conflict strategy in the current transaction lifecycle phase is reduced.

6. The conflict verification method based on transaction lifecycle phase awareness according to claim 1, characterized in that, After acquiring the transaction timing phase tracking data of the target transaction request in the design under test, the method further includes: The transaction timing phase tracking data is stored in a preset data packet buffer, and the conflict count corresponding to the target transaction request is updated. In response to detecting that the transaction timing phase tracking data contains an end phase tag indicating the completion of execution, and that the conflict counter corresponding to the target transaction request is not zero, the transaction timing phase tracking data is synchronized to a preset conflict counter, and the corresponding resources in the data packet buffer are released.

7. The conflict verification method based on transaction lifecycle phase awareness according to claim 1, characterized in that, The method further includes: The target transaction request and the conflicting transaction request sequence are simultaneously sent to a preset reference model; Obtain the execution results of the design under test and the processing results of the reference model; The execution result is compared with the processing result, and error feedback information is generated and output based on the comparison difference.

8. A conflict verification device based on transaction lifecycle phase awareness, characterized in that, include: The data acquisition module is used to acquire transaction timing phase tracking data of the target transaction request in the design under test; wherein, the transaction timing phase tracking data carries a timestamp and a phase tag corresponding to the transaction life cycle phase, and the transaction life cycle phase includes at least one of the following: initiation phase, transmission phase, initial phase, processing phase, listening phase, listening and processing phase, response phase, and completion phase; A strategy determination module is used to determine a target conflict strategy from a preset conflict strategy set based on the phase label and the timestamp. The target conflict strategy corresponds to a conflict-sensitive point following the current transaction lifecycle phase. The conflict strategy set includes at least one of the following: a resource full-load strategy corresponding to the initiation phase; a path congestion strategy corresponding to the transmission phase; a node congestion strategy corresponding to the initial phase; a state contention strategy corresponding to the processing phase; a listening interference strategy corresponding to the listening phase; a state interference strategy corresponding to the listening processing phase; a data pollution strategy corresponding to the response phase; and a timing interference strategy corresponding to the completion phase. The conflict-sensitive point includes at least one of the following: initial local resource capacity of the interconnection network, network link transmission and routing arbitrator congestion, node-processable request and retransmission resources, directory maintenance state machine contention, cache state machine and listening response interference, listening response and directory maintenance ordering, data and state consistency violation, and resource management logic allocation and release contention. The conflict verification module is used to generate a conflict transaction request sequence according to the target conflict strategy, and send the conflict transaction request sequence to the design under test for verification.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which enables the at least one processor to perform the conflict verification method based on transaction lifecycle phase awareness as described in any one of claims 1-7.

Images