Verification system, on-chip transaction verification method and device

Abstract

The application provides a verification system, an on-chip transaction verification method and device. The method is applied to a verification system corresponding to a system on chip. A uniform observation point is arranged at a port facing a plurality of request nodes of a master node agent of the system on chip. The method comprises the following steps: synchronously collecting key transaction information of each transaction through the uniform observation point of the port of the master node agent, wherein the key transaction information comprises an original ID, a source port, a target address, an operation code and a global timestamp; assigning a global unique identifier to each transaction, and writing the key information into a global transaction index structure by taking the global unique identifier as an index; dividing a plurality of transactions meeting preset conditions into a same associated group based on the same target address, the same original ID, operation code semantic dependence and a time interval of the time sequence difference being in a correlation interval, and establishing an intra-group association relationship in the index structure; and finally, acquiring the global timestamps of the transactions in each group, reorganizing the global timestamps into a complete processing link in a chronological order, and realizing time sequence restoration of out-of-order requests.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit verification, and in particular to a verification system, on-chip transaction verification method and apparatus. Background Technology

[0002] With the increasing integration of System-on-Chips (SoCs), multi-core processors, graphics processors, and various accelerators interact at high speed through Network-on-Chips (NoCs). To ensure data consistency, hardware consistency protocols (such as ARM Chi and ACE) are typically used to manage transaction interactions between multiple upstream Request Nodes (RNs) and the downstream storage subsystem. The Home Agent (HA), as the core hub of the consistency protocol, is responsible for receiving concurrent requests from different RNs and performing operations such as arbitration, directory lookup, snooping, and data forwarding to maintain the consistency of the global cache state.

[0003] In existing SoC verification processes, consistency verification for HA primarily relies on assertion checking in the simulation platform or port-based independent monitoring. Traditional verification methods typically deploy independent monitors on each RN port or HA port to record incoming and outgoing transaction packets separately. Due to the complex pipeline structure, arbitration logic, and cross-port dependencies within HA (e.g., a write request from one RN may trigger a sniffing response from another RN), transactions captured on different ports often arrive out of order and are logically scattered across different monitoring logs.

[0004] Existing technologies often struggle to accurately correlate sub-transactions (such as requests, sniffing, responses, and data) that are scattered across different ports and arrive at different times but belong to the same logical transaction when performing consistency checks. For example, when a protocol violation occurs, traditional methods can only locate the abnormal signal on a single port and cannot reconstruct the complete transaction processing chain spanning multiple RNs and HAs. This fragmented observation method requires debuggers to manually compare a large number of scattered logs, which is not only inefficient but also prone to missing hidden protocol errors caused by timing discrepancies, such as deadlocks, lost responses, or abnormal state machine transitions. Furthermore, existing methods lack a unified, global-perspective indexing mechanism to dynamically reassemble these out-of-order transactions, making it difficult to meet the increasingly complex chip design requirements in high-concurrency, large-scale interconnect scenarios in terms of verification coverage and debugging efficiency.

[0005] Therefore, how to accurately associate and restore the time sequence of out-of-order transactions is a technical problem that urgently needs to be solved. Summary of the Invention

[0006] In view of this, the present invention provides a verification system, an on-chip transaction verification method and apparatus to address the shortcomings of related technologies.

[0007] Specifically, the present invention is achieved through the following technical solution: According to a first aspect of the present invention, an on-chip transaction verification method is provided, applied to a verification system corresponding to an on-chip system, wherein the master node agent of the on-chip system is used to manage consistency transactions between multiple upstream requesting nodes and a downstream storage subsystem, and the master node agent has a unified observation point set at the port facing the multiple requesting nodes; the method includes: Through the unified observation point, transaction information of each transaction entering the master node agent is collected synchronously, wherein the key transaction information of each transaction includes at least the original transaction identifier, source port number, target address, opcode and global timestamp. Assign a global transaction identifier to each transaction, and use the global transaction identifier as an index to write the key transaction information of each transaction into the global transaction index structure; Based on the key transaction information, multiple transactions that meet the preset association conditions are divided into the same association group, and the association relationship between each associated transaction in each group is established in the global transaction index structure; wherein, the preset association conditions include: the same target address, the same original transaction identifier, the same opcode or the existence of a semantic dependency relationship defined by the protocol, and the global timestamp difference being within the time-series association interval; For each associated group recorded in the global transaction index structure, the global timestamps of each associated transaction in the group are obtained from the global transaction index structure, and the associated transactions in the group are reassembled into a complete processing chain according to the order of the global timestamps, so as to realize the time sequence restoration of out-of-order requests.

[0008] According to a second aspect of the present invention, a verification system is provided, wherein the on-chip system corresponding to the verification system includes a master node agent and a plurality of upstream request nodes and a downstream storage subsystem, the master node agent being used to manage consistency transactions between the plurality of request nodes and the storage subsystem, and the master node agent having a unified observation point set at a port facing the plurality of request nodes; the verification system includes a global port capturer, a global transaction index module, and a multi-dimensional cross-transaction matching engine, wherein, The global port capture device is used to synchronously collect transaction information of each transaction entering the master node agent through the unified observation point. The key transaction information of each transaction includes at least the original transaction identifier, source port number, target address, opcode and global timestamp. The global transaction index module is used to assign a global transaction identifier to each transaction and write the key transaction information of each transaction into the global transaction index structure using the global transaction identifier as an index. The multi-dimensional cross-transaction matching engine is used to divide multiple transactions that meet preset association conditions into the same association group according to the key transaction information, and to establish the association relationship between each associated transaction in each group in the global transaction index structure; wherein, the preset association conditions include: the same target address, the same original transaction identifier, the same opcode or the existence of a semantic dependency relationship defined by the protocol, and the global timestamp difference being within the time-series association interval. The transaction flow reassembler is used to obtain the global timestamps of each associated transaction in each associated group recorded in the global transaction index structure, and reassemble the associated transactions in the group into a complete processing link according to the order of the global timestamps, so as to realize the time sequence restoration of out-of-order requests.

[0009] According to a third aspect of the present invention, an on-chip transaction verification apparatus is provided, applied to a verification system corresponding to an on-chip system, wherein the master node agent of the on-chip system is used to manage consistency transactions between multiple upstream requesting nodes and a downstream storage subsystem, and the master node agent has a unified observation point set at a port facing the multiple requesting nodes; the apparatus includes: The observation unit is used to synchronously collect transaction information of each transaction entering the master node agent through the unified observation point, wherein the key transaction information of each transaction includes at least the original transaction identifier, source port number, target address, opcode and global timestamp. The archive unit is used to assign a global transaction identifier to each transaction and write the key transaction information of each transaction into the global transaction index structure using the global transaction identifier as an index. The association unit is used to divide multiple transactions that meet preset association conditions into the same association group according to the key transaction information, and to establish the association relationship between each associated transaction in each group in the global transaction index structure; wherein, the preset association conditions include: the same target address, the same original transaction identifier, the same opcode or the existence of a semantic dependency relationship defined by the protocol, and the global timestamp difference being within the time-series association interval; The reorganization unit is used to obtain the global timestamps of each associated transaction in each associated group recorded in the global transaction index structure, and reorganize the associated transactions in the group into a complete processing link according to the order of the global timestamps, so as to realize the time sequence restoration of out-of-order requests.

[0010] According to a fourth aspect of the present invention, an electronic device is provided, including a processor and a memory for storing processor-executable instructions; wherein the processor implements the method as described in the first aspect by executing the executable instructions.

[0011] According to a fifth aspect of the invention, a machine-readable storage medium is provided having computer instructions stored thereon that, when executed by a processor, implement the steps of the method as described in the first aspect.

[0012] As described above, the verification system and on-chip transaction verification scheme implemented by this invention, by setting a unified observation point at the ports of the master node agent facing multiple request nodes, can synchronously collect the original transaction data of all ports, breaking the information silos of traditional single-port monitoring. By assigning a globally unique global transaction identifier to each transaction and constructing a global transaction index structure, centralized management of cross-port transaction data is achieved. Furthermore, based on multi-dimensional conditions such as target address, original transaction identifier, opcode semantic dependency, and temporal correlation interval, scattered and disordered sub-transactions are accurately divided into the same association group, and intra-group correlation relationships are established. Finally, the transactions within the association group are reassembled temporally based on the global timestamp to restore the complete physical processing chain.

[0013] Understandably, by establishing a globally unified indexing and association mechanism, the system effectively overcomes transaction out-of-order issues caused by internal arbitration in HA, pipeline delays, and cross-port dependencies, achieving automated restoration from fragmented logs to the complete transaction chain. This not only significantly improves the coverage of protocol consistency verification but also enables technical personnel to intuitively track the entire lifecycle of any logical transaction, quickly pinpoint the root cause of protocol violations such as lost responses, deadlocks, or abnormal states, and significantly improve the efficiency and accuracy of SoC verification. Attached Figure Description

[0014] To more clearly illustrate the technical solutions of the present invention, the accompanying drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0015] Figure 1 This is a schematic diagram of the architecture of a system-on-a-chip and a verification system shown in an embodiment of the present invention; Figure 2 This is a schematic diagram of another system-on-a-chip and verification system architecture shown in an embodiment of the present invention; Figure 3 This is a flowchart illustrating an on-chip transaction verification method according to an embodiment of the present invention; Figure 4 This is a flowchart illustrating the workflow of a multidimensional cross-transaction matching engine according to an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating a full-link log generation sequence according to an embodiment of the present invention; Figure 6 This is a schematic structural diagram of an electronic device according to an embodiment of the present invention; Figure 7 This is a block diagram of an on-chip transaction verification device shown in an embodiment of the present invention. Detailed Implementation

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

[0017] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The singular forms “a,” “the,” and “the” used in this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0018] It should be understood that, depending on the context, the word “if” as used here can be interpreted as “when”, “when”, or “in response to determination”.

[0019] To address the aforementioned technical problems in related technologies, this solution proposes a novel verification system and further proposes an on-chip transaction verification method implemented by the system. This aims to solve the technical problem in related technologies where it is difficult to accurately correlate and restore the timing of consistent transactions that are scattered across different ports and arrive out of order, thus making it difficult to locate protocol anomalies.

[0020] The following is a detailed description of the scheme with reference to the accompanying drawings.

[0021] This invention first proposes a verification system for transaction verification of the master node agent in an on-chip system. The master node agent connects upstream to multiple request nodes and downstream to a storage subsystem, together constituting the on-chip system. The master node agent manages consistency transactions between the multiple request nodes and the storage subsystem. This solution innovatively sets a unified observation point at the port of the master node agent facing the multiple request nodes. The verification system includes a global port capturer, a global transaction index module, and a multi-dimensional cross-transaction matching engine, wherein… The global port capture device is used to synchronously collect transaction information of each transaction entering the master node agent through the unified observation point. The key transaction information of each transaction includes at least the original transaction identifier, source port number, target address, opcode and global timestamp. The global transaction index module is used to assign a global transaction identifier to each transaction and write the key transaction information of each transaction into the global transaction index structure using the global transaction identifier as an index. The multi-dimensional cross-transaction matching engine is used to divide multiple transactions that meet preset association conditions into the same association group according to the key transaction information, and to establish the association relationship between each associated transaction in each group in the global transaction index structure; wherein, the preset association conditions include: the same target address, the same original transaction identifier, the same opcode or the existence of a semantic dependency relationship defined by the protocol, and the global timestamp difference being within the time-series association interval. The transaction flow reassembler is used to obtain the global timestamps of each associated transaction in each associated group recorded in the global transaction index structure, and reassemble the associated transactions in the group into a complete processing link according to the order of the global timestamps, so as to realize the time sequence restoration of out-of-order requests.

[0022] In some embodiments, the verification system may be deployed inside the master node agent. Figure 1 This is a schematic diagram illustrating the architecture of a system-on-a-chip and a verification system according to an embodiment of the present invention. Figure 1 As shown, the verification system is fully integrated within the master node agent. In this architecture, the entire on-chip system is divided into three main layers: the upstream request layer, the core hub layer, and the downstream storage layer.

[0023] The upstream request layer comprises multiple request nodes (RNs, such as RN1 to RN4), which can be CPU cores, GPU accelerators, or DMA controllers, etc. They send consistency transaction requests to the core hub layer through their respective ports. The core hub layer is primarily a master node proxy HA. Unlike conventional HA, the HA in this embodiment not only includes standard RN ports (such as RN1 to RN4 ports), but also embeds (deploys) a complete verification system.

[0024] The RN port can be one of four independent channels defined by the hardware conformance protocol, such as Request (REQ), Response (RSP), Sniffing (SNP), and Data (DAT). Each channel can have an independent protocol checker deployed on it. The working principle of each channel checker is as follows: REQ channel checker: Verifies whether the request transaction received by this port conforms to the protocol format constraints, whether the transaction state machine transition is legal, and whether the request meets the legality preconditions defined by the hardware consistency protocol. RSP channel checker: Verifies whether the response transaction received on this port is correctly matched with the previously sent request transaction at the TxnID level, and whether the response type conforms to the legal response set specified by the protocol; SNP channel checker: Verifies whether the Snoop requests and responses sent and received on this port conform to the Snoop interaction specifications of the hardware conformance protocol. DAT channel checker: Verifies whether the data transmission transaction on this port is correctly matched with the corresponding request or response at the TxnID and data length level.

[0025] Each channel checker can run independently, recording detected protocol violation events to a local log file. They do not need to share transaction information or establish cross-port transaction associations with each other.

[0026] The verification system built into the system-on-chip consists of four tightly coupled functional modules that form a closed-loop data processing pipeline within the HA: Global Port Capturer: Located at the intersection or bypass position of all RN ports within the HA, it is used to manage and invoke the unified observation point. It directly listens to all raw protocol data (Flits) flowing through the HA ports through the unified observation point, synchronously collecting key transaction information including at least the original transaction identifier, source port number, destination address, opcode, and global timestamp. Because it is deployed inside the HA, the capturer can directly acquire low-latency, high-precision timing signals through the internal high-speed bus.

[0027] Global Transaction Index Module: This module receives data from the capture unit and assigns a globally unique global transaction identifier (GlobalTxnID) to each transaction. It maintains a global transaction index structure (such as a hash table), where key transaction information and associated pointer lists can be written using the GlobalTxnID as the key. This module enables centralized management of cross-port data.

[0028] The multi-dimensional cross-transaction matching engine and transaction flow reorganizer are the computational core of the verification system. The former reads data from the global transaction index, executes complex four-level filtering logic (such as target address → original ID → opcode semantics → time sequence interval), divides transactions that are scattered across different ports and arrive out of order into the same association group, and establishes intra-group associations. The latter sorts and reorganizes transactions within the group based on the global timestamp, restoring the complete physical processing chain.

[0029] Additionally, the verification system may include a full-link log generator and a sniffing filter based on consistency goals (not shown in the figure). The full-link log generator is used to generate verification logs. The sniffing filter is used to assist in determining the transaction status, thereby supporting anomaly detection. Although it is listed as part of the verification system in the figure, in the built-in architecture, it may share resources with the original hardware consistency catalog of HA or exist independently.

[0030] The downstream storage layer can connect to the HA (High Availability) via a memory controller to complete the final data read and write operations. This is understandable. Figure 1 The key to the integrated architecture shown is "zero external dependencies," meaning that all acquisition, indexing, matching, and reassembly logic is completed within the HA chip. Verification results can be directly output through the HA's diagnostic registers or exported through dedicated debug interfaces (such as JTAG / DBI). This architecture makes the verification system an integral part of the SoC, possessing extremely high real-time performance and independence.

[0031] In other embodiments, the verification system may also be independent of the master node agent (i.e., deployed outside the master node agent). Figure 2 This is a schematic diagram of another system-on-chip (SoC) and verification system architecture shown in an embodiment of the present invention. The diagram illustrates an architecture in which the verification system is deployed outside the HA and runs independently of the SoC. This separate architecture also includes an upstream request layer, a core hub layer, and a downstream storage layer, but its data flow and verification mechanism implementation differ significantly from the aforementioned integrated architecture.

[0032] At the upstream request layer and downstream storage layer, the separate architecture remains consistent with the aforementioned integrated architecture. RN1 through RN4 initiate requests, and data ultimately flows to the storage subsystem via the core hub layer. The master node agent HA at the core hub layer maintains its standard hardware functions in this architecture, namely, arbitrating the consistency protocol, managing the directory, and forwarding data.

[0033] However, instead of integrating complex verification logic modules internally, the HA (High-Ahead Controller) uses a lightweight unified observation point at the boundary facing multiple RN (Remote Receiver) ports. This unified observation point acts as a bridge between the SoC under test (SoC) and the external verification system. It can consist of a set of high-bandwidth signal probes or mirror ports, responsible for non-intrusively bypassing and monitoring all communication traffic on the HA ports. Once raw protocol data is captured, it can be transmitted in real time to the verification system located outside the SoC via high-speed debug interfaces such as DMI, AXI-Trace, or a dedicated debug bus.

[0034] The external verification system is a standalone logical entity that can run on high-performance workstations, servers, or dedicated hardware emulation accelerators. This system also contains four core modules, but its implementation is typically in the form of software components (such as UVM Monitor / Scoreboard) or FPGA logic. Global port capture: It can be represented as a data receiving interface, responsible for parsing the raw data stream from a unified observation point, extracting key transaction information, and classifying and archiving it.

[0035] Global Transaction Index Module: This module constructs a massive global transaction index structure in external memory (such as DRAM). Because it is not limited by chip area, it can maintain extremely large hash tables and pointer lists, supporting indexing of massive concurrent transactions.

[0036] Multidimensional cross-transaction matching engine: Utilizing the powerful computing power of external processors, it executes complex multidimensional association algorithms, which can handle more complex semantic dependency judgments and longer-window time-series analysis logic than the built-in engine.

[0037] Transaction flow reassembler: Utilizes the powerful computing capabilities of external processors to perform complex time-series reassemblies.

[0038] Similarly, the verification system may also include a full-link log generator and a sniffing filter (not shown in the figure), which will not be elaborated further.

[0039] Figure 2The key to the decoupled architecture shown lies in "decoupling." The SoC under test does not need to bear the hardware area and power consumption overhead of the verification logic, while the verification system can be flexibly upgraded, dynamically configured, and utilize unlimited external computing resources for in-depth analysis. Verification results are generated directly on the external host, facilitating interaction and debugging by technicians through a graphical interface.

[0040] The two architectures mentioned above differ in many ways: First, there are physical location and resource constraints: Figure 1 The integrated architecture of the SoC is limited by the silicon area and power consumption of the SoC. Therefore, its internal verification modules often need to undergo extreme hardware optimization, which may require simplification of certain complex algorithms (such as using fixed timing windows instead of dynamic calculations). Figure 2 The separate architecture does not have this limitation and can utilize the almost unlimited memory and computing power of external servers to implement full-featured, high-precision verification logic.

[0041] Secondly, there's the issue of real-time performance and latency: integrated architectures offer microsecond-level or even nanosecond-level real-time response capabilities, enabling them to complete correlation and anomaly marking the instant a transaction occurs, making them suitable for online monitoring. Decoupled architectures, on the other hand, involve data transmission and external processing, resulting in some latency, making them more suitable for offline verification during post-analysis or simulation phases.

[0042] Secondly, there's the issue of flexibility and maintainability: the software nature of a discrete architecture makes it easy to upgrade. When the conformance protocol version is updated, only the external verification code needs to be updated, without modifying the chip hardware. In contrast, once an integrated architecture is tapered, the verification logic is fixed, resulting in less flexibility, but it does have "black-box" testing capabilities, meaning it can still work even without access to an external simulation environment.

[0043] As can be seen, the two architectures described above each possess different technical advantages and are applicable to different technical scenarios. For example, the integrated architecture is suitable for on-site debugging and fault reproduction scenarios. When a chip is packaged and deployed in an end device, and sporadic deadlocks or data errors occur, the built-in verification system can act as a "black box" to record and reconstruct the on-site transaction chain, without relying on expensive external simulation equipment. It is also suitable for production testing (DFT) scenarios, such as the post-chip manufacturing testing phase, where the built-in verification logic can be used to quickly screen for hardware defects in the implementation of consistency protocols. Furthermore, it is suitable for security-sensitive environments, such as security scenarios where data is not allowed to flow out of the chip; the built-in verification can complete the audit internally and only output summary results. The discrete architecture, on the other hand, is suitable for the RTL simulation verification stage, such as in the early stages of chip design, using platforms like UVM (Universal Verification Methodology) for large-scale regression testing. This requires covering millions of transactions, and the external system can efficiently handle massive logs and provide rich visual debugging interfaces. It can also be used for hardware simulation acceleration. For example, when using hardware accelerators such as Palladium / Zebu, the external verification system can run on a host server and interact with the model under test through a high-speed interface to balance speed and verification complexity. It is also suitable for protocol development and iteration. For instance, when the consensus protocol is not yet finalized and frequent adjustments to correlation algorithms and timing parameters are required, the agile development characteristics of the split architecture make it the preferred choice. In application, the specific architecture used to deploy the verification system and on-chip system can be reasonably selected based on the actual scenario and verification requirements; this embodiment of the invention does not impose any restrictions on this.

[0044] In one embodiment, the verification system can be implemented based on the UVM platform. The global port capturer, the global transaction index module, and the multidimensional cross-transaction matching engine can each be implemented as independent UVM components and dynamically configured to be enabled or disabled via a UVM configuration database (uvm_config_db). Furthermore, the UVM configuration database can also be used to dynamically adjust the width of the timing correlation interval during system runtime. This embodiment instantiates the global port capturer, the global transaction index module, and the multidimensional cross-transaction matching engine as independent UVM components and utilizes the UVM configuration database for runtime state management, enabling modular assembly, flexible start / stop, and resource optimization of the verification environment.

[0045] The independent UVM component refers to a software object built according to the UVM standard class library structure. Each component can inherit from the uvm_component or uvm_monitor / agent base class, and has standard lifecycle management interfaces (such as build_phase, connect_phase, run_phase). It can be written in SystemVerilog and registered and created using the Factory Pattern to achieve dynamic replacement of component types. The UVM configuration database is a global key-value pair storage mechanism provided by the UVM framework, used to pass configuration parameters between component levels. This database can use strings as keys and any SystemVerilog data type as values, supporting top-down or cross-level parameter injection. The so-called "dynamic configuration to enable or disable state" refers to controlling the execution logic of the main loop (main_phase or run_phase) inside the component by reading the boolean or enumerated flags in the configuration database. This control can be implemented using conditional statements combined with process suspension (wait / process suspension) or no-op logic, thereby changing the component behavior without rebuilding the simulation environment.

[0046] Taking a regression testing scenario for a large-scale multi-core SoC as an example, in this scenario, the verification platform needs to run thousands of test cases simultaneously. Some of these test cases only focus on memory read / write performance and do not require complex consistency protocol checks. In this case, configuration items can be written to uvm_config_db during the build_phase of the top-level test bench, for example, setting "enable_consistency_check" to 0. When the simulation starts, the two computationally intensive UVM components, the global transaction index module and the multi-dimensional cross-transaction matching engine, read this configuration during the initialization phase. Finding that the flag is off, they skip the time-consuming hash table construction and association matching algorithm execution and directly enter idle waiting or bypass mode.

[0047] In specific debugging scenarios targeting deadlock issues, technicians can set the configuration item to 1 and further inject specific filtering rules (such as monitoring only transactions within a specific address range) into the configuration database. At this point, the global port capturer is activated, begins collecting data and passing it to subsequent modules, and the multi-dimensional cross-transaction matching engine adjusts the width of the time-series correlation interval based on the injected parameters, thereby accurately capturing abnormal links. This dynamic control based on the configuration database allows the same set of verification code to adapt to different needs, from lightweight smoke testing to heavy stress testing, without modifying the source code or recompiling the simulation model.

[0048] This embodiment addresses the technical problems of poor flexibility, high resource consumption, and low debugging efficiency in static verification environments. By adopting an independent UVM component-based design, it achieves high cohesion and low coupling of verification functions, allowing each module to be developed, verified, and reused independently, thereby improving the maintainability and scalability of the verification system and facilitating parallel development. Secondly, utilizing the UVM configuration database for dynamic start-stop control avoids ineffective computational resource consumption in inconsistency testing scenarios. By skipping complex index building and matching logic, it significantly reduces simulation memory usage and CPU time, contributing to improved overall throughput in regression testing. Furthermore, this dynamic configuration mechanism allows seamless switching of verification strategies during simulation runtime or between different test cases. Since the observation granularity and inspection scope can be adjusted without restarting the simulator, it greatly shortens the debugging iteration cycle and enhances the accuracy of locating hidden protocol errors.

[0049] Of course, if the above functional modules are not implemented based on UVM software components, other methods are also possible. For example, virtual components based on Hardware Description Language (HDL) can be used. For instance, logic such as global port capture and indexing modules can be encapsulated as standardized IP core interfaces and called in the simulation environment via Bus Function Model (BFM). This approach maintains a high degree of consistency with the hardware RTL code, facilitating the direct reuse of silicon-proven logic modules, while also improving execution speed through a hardware-accelerated emulator. Alternatively, a hybrid simulation architecture can be used, offloading the computationally intensive matching engine to an external C / C++ program that interacts via the DPI-C interface. This approach leverages the performance advantages of C language in handling large-scale data structures to accelerate the correlation analysis of massive transactions, while retaining the convenience of SystemVerilog in interface drivers, achieving efficient verification through software and hardware collaboration.

[0050] The specific ways in which each functional module in the above verification system implements its corresponding function can be found in the detailed description of the embodiments below, and will not be repeated here.

[0051] Figure 3 This is a flowchart illustrating an on-chip transaction verification method according to an embodiment of the present invention. This method can be applied to the aforementioned verification system, specifically, it is implemented through the cooperation of the aforementioned global port capture device, global transaction index module, and multi-dimensional cross-transaction matching engine. The method includes the following steps 302-308.

[0052] Step 302: Through the unified observation point, synchronously collect the transaction information of each transaction entering the master node agent, wherein the key transaction information of each transaction includes at least the original transaction identifier, source port number, target address, opcode and global timestamp.

[0053] This step employs a global data capture mechanism based on a unified observation point. It synchronously monitors the traffic of each port on the master node proxy and extracts key fields to build the raw data foundation required for subsequent processing. The unified observation point described in this invention is a non-intrusive monitoring probe deployed at the physical or logical interface of the master node proxy facing multiple requesting nodes. This observation point is used to mirror the protocol messages of all incoming and outgoing ports in real time without interfering with normal business flow. Specifically, it can be implemented using hardware bypass circuits (such as TAP controllers, dedicated mirror ports) or interface monitors in a simulation environment, for example, a high-bandwidth sampling module connected to an AXI / CHI bus. The key transaction information refers to the smallest set of fields parsed from the original protocol messages that is sufficient to uniquely identify and describe the transaction attributes (i.e., using a set of key transaction information, a specific transaction can be located). This information is used for subsequent identity recognition, association matching, and state restoration. The key transaction information can be in the format of a structure or record object, for example, it can contain a 64-bit original transaction ID, an 8-bit source port number, a 48-bit target physical address, an 8-bit opcode, and a 64-bit global simulation timestamp.

[0054] After the verification system starts, the global port capture can continuously poll or interrupt-triggeredly read signal levels or data packets at a unified observation point. When a valid transaction header is detected, the parser immediately extracts fields such as TxnID, SrcPort, Addr, and Cmd from the packet header and generates a global timestamp by combining them with the current system clock. These fields can be encapsulated into standardized key transaction information objects and temporarily stored in a buffer queue. This step is the data entry point for the entire verification process. Its function is to transform the underlying heterogeneous and parallel physical signals into standardized data structures that can be processed by the upper-layer software, providing a clean and complete input source for index building in subsequent steps, ensuring that no concurrent events are missed in subsequent analysis.

[0055] In one embodiment, when synchronously collecting transaction information through the unified observation point, the original protocol data of each transaction entering the master node proxy can be collected synchronously through the unified observation point first. Then, the original protocol data is parsed to obtain key transaction information and transaction type for each transaction. Finally, according to the transaction type, the key transaction information is classified and archived into a request queue, response queue, sniffing queue, or data queue. The archived key transaction information can then be used to perform subsequent association grouping steps. This embodiment is essentially a transaction data preprocessing and classification archiving mechanism based on protocol semantics. It synchronously collects original protocol data through a unified observation point and parses out key transaction information and transaction type, then distributes the key transaction information to request, response, sniffing, or data queues according to the transaction type, providing a structured and ordered data foundation for subsequent multi-dimensional association matching.

[0056] The raw protocol data refers to the underlying signal sequence or bit stream physically transmitted on the HA port of the master node agent, which typically follows a specific hardware conformance protocol specification (such as ARM Chi, ACE, or a custom proprietary protocol). Parallel bus signals can be captured using shift registers in hardware logic, or the raw protocol data can be collected in a simulation environment by sampling the level state on the clock edge using an interface monitor. The transaction type is a logical classification label for transactions according to the protocol definition, such as distinguishing whether the transaction is a read / write request, a response returning a result, a snoop for maintaining consistency, or actual transmitted payload data. The transaction type of any transaction can be determined by parsing the Opcode field or Channel ID in the packet header and mapping it to a predefined enumeration type. "Classification archiving" is the process of distributing key transaction information to different logical storage buffers based on the parsed transaction type. Among them, a logical structure combining a multiplexer with a first-in-first-out (FIFO) queue or a ring buffer can be used to implement classified archiving, so as to ensure that different types of transaction data are stored in isolation, which facilitates subsequent retrieval and processing according to specific strategies.

[0057] Take, for example, a scenario involving a multi-core processor cluster performing a complex memory consistency test. In this scenario, multiple CPU cores (acting as request nodes, RNs) concurrently send a large number of read and write requests to the master node proxy HA. First, a unified observation point deployed at each input port of HA monitors bus activity in real time. When it detects that RN1 has initiated a write request for address 0x1000, the capture module synchronously collects the raw Flit data at that moment. Next, the parsing module intervenes. It identifies that the message header indicates that this is a "WriteReq" type request, and extracts the original transaction ID (e.g., TxnID=0xA1), source port (Port=1), destination address (Addr=0x1000), opcode (Op=Write), and the current global simulation timestamp (T=100ns) from the message, assembling these fields into a key transaction information record. Subsequently, the classification logic determines that the record belongs to the "request" type and pushes it into the "request queue" for temporary storage. Meanwhile, HA might send a sniffing request to RN2 to invalidate its cache line. The observation point also captures this downlink traffic, parses it as "Snoop," and pushes key information containing the same target address but different opcodes into the "sniffing queue." Later, when RN2 returns a sniffing response, or HA issues a write request to memory, the corresponding key information is archived into the "response queue" and "data queue," respectively. This parallel and categorized processing flow ensures that even under high concurrency pressure, transaction data from different directions and of different natures can be orderly collected, avoiding processing bottlenecks caused by data mixing. Finally, during subsequent association group partitioning, the request with TxnID=0xA1 can be retrieved from the request queue, and the corresponding entry with the same target address and time window can be quickly searched in the sniffing queue and response queue, thereby efficiently reassembling the complete interaction chain.

[0058] This embodiment addresses the technical problems of low matching efficiency and resource waste caused by the heterogeneity, out-of-order arrival, and lack of structured organization of original protocol data in existing technologies. By parsing the original protocol data and extracting key transaction information, the data format is standardized and simplified. By removing redundant control bits and padding bits from the protocol messages, the amount of data that the subsequent index structure and matching engine need to process is significantly reduced, improving the overall system throughput. Secondly, by classifying and archiving transactions according to type, a semantic-based data isolation mechanism is established. Since different types of tasks are distributed into independent queues, subsequent matching algorithms can perform targeted searches in specific queues (e.g., searching for the starting point only in the request queue and the ending point only in the response queue), avoiding the huge computational overhead of full scanning and significantly shortening the time delay of transaction reorganization. Furthermore, this preprocessing mechanism enhances the scalability and protocol compatibility of the verification system. Because the parsing and classification logic can be designed as configurable plug-in modules, the system can flexibly adapt to different versions or types of consistency protocols, supporting new transaction types without refactoring the core association algorithm, thus improving the reusability of the verification platform across different projects.

[0059] Besides the aforementioned classification and archiving scheme based on fixed queue types, a priority-weighted event-driven caching scheme can also be used for data processing. For example, different priority weights can be assigned to each type of transaction, and all critical transaction information can be stored uniformly in a priority stack or priority queue. High-priority transactions (such as blocking requests that may lead to deadlocks) are retrieved and processed first. This scheme ensures that critical abnormal transactions receive immediate responses, reduces the latency of detecting serious errors, and simplifies memory management logic and reduces fragmentation overhead through a unified storage structure. Alternatively, a hash-based distributed archiving scheme can be used. For example, based on the high-order hash value of the target address, critical transaction information can be distributed to multiple parallel sub-queues, and each sub-queue can be further subdivided according to transaction type. This scheme can leverage the parallel processing capabilities of multi-core processors to achieve load balancing of large-scale concurrent transactions, significantly improving the system's data ingestion capability in ultra-high bandwidth scenarios, while also improving cache hit rate and optimizing overall processing performance through the principle of locality.

[0060] Step 304: Assign a global transaction identifier to each transaction, and write the key transaction information of each transaction into the global transaction index structure using the global transaction identifier as an index.

[0061] This step employs a centralized index construction method based on globally unique identifiers. By assigning a global ID to each transaction and writing it into a hash table structure, it enables fast storage and random access to massive concurrent transactions. The global transaction identifier (GlobalTxnID) assigned to a transaction is a unique digital label dynamically generated by the verification system during the acquisition phase, valid throughout the entire simulation cycle. This identifier resolves potential conflicts between local IDs of different request nodes and can serve as the primary key of the global index. Specifically, this identifier can be generated using an incrementing counter, timestamp concatenation, or a hash algorithm; for example, it can be a 128-bit unsigned integer composed of "high-order timestamp + low-order port ID + local sequence number". The global transaction index structure refers to a memory database or lookup table used to centrally manage all acquired transaction data, supporting O(1) complexity fast retrieval and updates based on GlobalTxnID. This structure can be implemented using a hash table, a balanced binary search tree, or a columnar database; for example, it can be an open-addressable hash table with GlobalTxnID as the key and a structure containing key information and a list of null pointers as the value.

[0062] In this step, after receiving critical transaction information, the system calls the ID generator to assign a brand new GlobalTxnID. Then, it calculates the hash value of this ID to determine the bucket location, writes the critical transaction information into the corresponding Value field, and initializes the associated pointer list to empty. If a hash collision occurs, chaining or linear probing is used to resolve it. This step transforms the streaming data collection into static, searchable records, providing an efficient data foundation for subsequent multidimensional matching. It ensures that when handling millions of concurrent transactions, the location latency of any transaction remains constant, avoiding becoming a performance bottleneck.

[0063] In one embodiment, the global transaction index structure can be implemented using a hash table, wherein: the key of the hash table is the global transaction identifier; and the value of the hash table can be a structure containing the key transaction information and a list of associated pointers. Under this hash table structure, the list of associated pointers can be used to store pointers to entries of other transactions within the same association group in the global transaction index structure, thereby forming an association topology between transactions.

[0064] This embodiment employs a global transaction indexing mechanism based on hash tables and associated pointer lists. Data is organized using a global transaction identifier as the key and a structure containing key transaction information and an associated pointer list as the value. This enables efficient storage, fast retrieval, and dynamic maintenance of logically related topologies for cross-port out-of-order transactions. The hash table key (Key) is an index value used to uniquely identify and locate a specific transaction record. In this scheme, it specifically refers to the global transaction identifier assigned to each transaction. This identifier can be a 64-bit or 128-bit unsigned integer, generated by combining the high-order bits of the timestamp, the source port ID, and a local counter to ensure global uniqueness during simulation or runtime. Correspondingly, the hash table value (Value) refers to the data payload corresponding to the key, stored in the hash bucket. This value can be a custom structure or class object, which encapsulates key transaction information obtained from protocol parsing (such as address, opcode, status, etc.) and a dynamically sized associated pointer list. The associated pointer list is a collection of references used to record the logical dependencies between the current transaction and other transactions. Specifically, it can be implemented using an array of pointers storing memory addresses, a list of references storing global transaction identifiers, or a doubly linked list. These pointers point to the specific entries of other transactions within the same association group in the global index structure, thus establishing a logical network connection between physically distributed data.

[0065] Consider a complex interaction scenario involving multi-core processors executing cache coherency protocols (such as the CHI protocol). In this scenario, assume CPU core A initiates an exclusive write request (WriteUnique) to address 0x1000, while CPU core B happens to hold a shared copy of that address. First, the verification system captures core A's request, assigns it a global transaction identifier GT_ID_1, and stores the key information of the request in a hash table; at this point, its associated pointer list is empty. Subsequently, the master node agent HA sends a sniff request (SnoopShared) to core B. The verification system captures this downstream transaction and assigns GT_ID_2. During the parsing process, the matching engine discovers that the target address of GT_ID_2 is the same as GT_ID_1, and there is a semantic dependency (the sniffing is triggered by the write request). Therefore, GT_ID_2 is written to the hash table, and pointer references to each other are added to the associated pointer lists of GT_ID_1 and GT_ID_2. Next, core B returns a sniff response (SnoopResp), assigns GT_ID_3, adds it to the associated group, and updates the pointer lists of GT_ID_1, GT_ID_2, and GT_ID_3, forming a triangular topology interconnected by the three. Finally, when core A receives the completion response, it assigns GT_ID_4 and links it to the group. Through this pointer-based dynamic linking method, regardless of how out-of-order these transactions arrive on the timeline, or which port's queue they reside in, as long as the hash table is accessed through GT_ID_1, the entire interaction chain involving cores A and B and HA can be instantly traversed by following the pointer list, without requiring time-consuming full table scans or secondary queries.

[0066] This embodiment addresses the technical challenges of traditional linear log storage methods, such as difficulty in transaction association lookup, poor memory access locality, and high complexity of reorganization algorithms. By employing a hash table as the index base and using global transaction identifiers as the direct addressing keys, the average time complexity of hash lookup is close to O(1), enabling millisecond-level rapid location of massive concurrent transaction data and significantly reducing retrieval latency. Secondly, by embedding a list of associated pointers in the value structure, an explicit logical topology between transactions is established. This avoids repeated condition matching and scanning of global data during the reorganization phase, thereby significantly reducing CPU computational overhead and making the time-series restoration process more efficient and smooth. Furthermore, this structured storage method enhances the spatial locality and cache friendliness of data. Since associated transaction pointers often point to nearby or predictable memory regions (depending on the hash algorithm and allocation strategy), the processor cache hit rate is improved, further optimizing the overall system performance in large-scale simulation environments.

[0067] Of course, besides implementations based on hash tables and pointer lists, external storage solutions based on relational databases or graph databases can also be used for transaction index management. For example, a global transaction identifier can be used as the primary key, and relationships can be stored as edges in a graph database, using graph query languages ​​such as Cypher or Gremlin for path retrieval. This approach can leverage mature database engines to handle extremely large datasets, support persistent storage and complex multi-hop queries, and facilitate long-term archiving and in-depth analysis. Alternatively, a hybrid approach combining Bloom filters and inverted indexes can be used. For example, a Bloom filter can be used to quickly eliminate irrelevant transactions, then an inverted index built for the target address and opcode can be used to locate the candidate set, and finally a temporary relationship graph can be built in memory. This approach can significantly compress index space usage in extremely memory-constrained embedded verification scenarios while maintaining high query filtering efficiency, making it suitable for resource-sensitive on-chip self-verification systems.

[0068] In one embodiment, the key transaction information may further include response codes and / or cache states. To address this, when writing the key transaction information for each transaction into the global transaction index structure, the response codes and / or cache states in the key transaction information can first be mapped to preset standard state values, and then the standard state values ​​are written into the global transaction index structure. This embodiment employs a normalization processing mechanism for specific fields in the key transaction information. By extracting the response codes and cache states from the original protocol fields and mapping them to preset standard state values, while retaining the original fields of other key transaction information, it aims to eliminate semantic differences between different protocol versions or hardware architectures, thereby achieving standardization and unification of the verification data format.

[0069] The response code is a status identifier in the consistency protocol used to indicate the result of transaction execution, such as success, failure, retry, or error type. It can be an enumeration value defined by the protocol (such as the RespErr field in ARM CHI), typically occupying several bits. The cache state is the coherence state of data in the cache level, such as exclusive, shared, or invalid, which can be implemented using state machine encoding (such as the encoding of the MESI or MOESI protocol). The preset standard state values ​​are a set of general state enumerations defined internally by the verification system, independent of specific hardware protocols. Specifically, they can be unified integer codes or string labels, for example, mapping various protocol-specific "SlvError" and "DecError" to the standard state "ERR_SLAVE", and mapping "CleanShared" and "DirtyShared" to "STATE_SHARED", etc. The normalization process described above can be implemented using a look-up table (LUT), state mapping function, or conditional statement. This processing can target only the response code and cached state—two volatile and protocol-dependent fields—while fields with physical uniqueness or fixed formats, such as the original transaction identifier, destination address, and source port number, are directly passed through and written without conversion. Alternatively, all critical transaction information can be normalized before writing, but this will not be elaborated further.

[0070] Taking a SoC verification platform supporting multiple generations of ARM CHI protocols (such as CHI-E to CHI-I) as an example, in this scenario, different versions of the protocol may have subtle differences in the definition of response errors. For instance, CHI-E may use a specific bit combination to represent "address decoding error," while CHI-I may introduce new error codes or change the encoding method. If the original fields are used directly, the verification system's correlation matching engine and anomaly detection module would need to write a large number of if-else branches to be compatible with different protocols, resulting in bloated and difficult-to-maintain code. In this solution, when the capture device collects a write request response from the CHI-E protocol, it parses its original RespErr as 0x2 (assuming it represents a decoding error). The normalization module queries the mapping table and converts it to the standard status value STD_ERR_DECODE. Subsequently, when a similar response from the CHI-I protocol is collected, even if its original encoding is 0x5, the normalization module maps it to the same STD_ERR_DECODE. In these two transactions, the address, ID, and timestamp retain their original binary values, but the response code field is changed to a unified standard value. Next, the system writes the structure containing `STD_ERR_DECODE` into the global transaction index structure. Subsequent multi-dimensional matching engines, when performing anomaly detection, only need to check if the standard status value equals `STD_ERR_DECODE`, without needing to know whether the underlying protocol is CHI-E or CHI-I. This approach allows the same verification logic to seamlessly adapt to multiple protocol versions, greatly improving the versatility and reusability of the verification platform.

[0071] This embodiment addresses the technical problems in existing technologies, such as complex verification logic, poor compatibility, and difficulties in data comparison caused by protocol version iterations or architectural differences. By normalizing the mapping of response codes and cache states, the differences in underlying protocol implementations are masked. Since the core verification algorithm relies only on unified standard state values, the code complexity of the matching engine and log generation module is significantly reduced, improving software maintainability. This standardization ensures the consistency of verification data across projects and generations of chips. Because transaction information from different sources has the same semantic expression in key fields, historical fault databases and error correction suggestion databases can be shared by multiple projects, avoiding the cost of rebuilding the knowledge base for each new protocol. Furthermore, by retaining the original values ​​of other fields, debugging accuracy can be ensured. Since fields such as address and ID are not modified, it ensures that the actual physical signal state can be traced when locating specific hardware faults. This mechanism improves the general efficiency of upper-layer logic while retaining the necessary details of lower-layer debugging, achieving a balance between the abstraction layer and the physical layer.

[0072] In addition, a dynamic parsing scheme based on Intermediate Description Language (IDL) can be used for field standardization. For example, a separate protocol description file (such as XML or JSON format) can be predefined, declaring the correspondence between response codes and cache states for each protocol version and standard values. The verification system can load this description file and dynamically generate mapping logic upon startup. This scheme supports runtime hot updates of protocol rules, adapting to newly emerging proprietary protocol variants without recompiling the verification platform, greatly improving the system's flexibility and scalability. Alternatively, an automatic classification mapping scheme based on machine learning models can be used. For example, a lightweight classifier can be pre-trained, taking the bit patterns of the original protocol fields as input and outputting the predicted standard state categories. This scheme can handle unstructured or highly complex proprietary protocol fields, automatically inferring semantics through pattern recognition. It is suitable for verification scenarios of legacy systems or black-box IP cores lacking explicit documentation support, lowering the barrier to manually extracting mapping rules.

[0073] Step 306: Based on the key transaction information, multiple transactions that meet the preset association conditions are divided into the same association group, and the association relationship between each associated transaction in each group is established in the global transaction index structure; wherein, the preset association conditions include: the same target address, the same original transaction identifier, the same opcode or the existence of a semantic dependency relationship defined by the protocol, and the global timestamp difference being within the time-series association interval.

[0074] This step employs a transaction association algorithm based on multi-level short-circuit filtering. It filters transactions using four conditions: address, ID, semantics, and time sequence, to accurately cluster out-of-order sub-transactions scattered across different ports into the same logical group. The preset association conditions refer to a set of logical rules for determining whether multiple independent transactions belong to the same complete processing link (i.e., a consistent interaction link). These conditions eliminate irrelevant noise and lock down a subset of transactions with causal dependencies. Specifically, they can take the form of Boolean logic expressions or state machine transition tables, such as "equal target addresses," "consistent original TxnIDs," "opcodes exhibit read / write / sniffing dependencies," and "time difference less than the microarchitecture latency threshold." The association group is the set of all sub-transactions determined to belong to the same logical transaction lifecycle. This group serves as the basic unit for time-series reordering, ensuring link integrity. This group can be implemented using a doubly linked list, graph structure, or array references. For example, it can be a pointer network containing a root node (request) and all its derived nodes (sniffing, response, data), where each node points to each other through an associated pointer list.

[0075] In this step, the matching engine traverses the global index, first filtering the candidate set using the target address as the primary key to narrow down the search scope; then comparing the original TxnID and opcode semantics within the candidate set to exclude irrelevant accesses; finally, it checks whether the global timestamp difference is within the dynamically calculated time-series window. Transactions that meet all conditions are marked as belonging to the same group, and their associated pointer lists are updated in their respective index entries, forming a cross-reference relationship. This step solves the problem of cross-port data fragmentation, logically stitching together physically separated log fragments, providing a structured topology foundation for subsequent time-series reconstruction, and ensuring that the reconstructed chain not only contains the correct transactions but also has a clear dependency direction.

[0076] The time-series correlation interval refers to the time threshold range used to determine whether there is a logical causal relationship between two or more transactions. It can be implemented by a positive and negative deviation interval [T-δ, T+δ] based on the global timestamp or a one-way delay upper limit δ. If the timestamp difference between any two transactions falls within this interval, the two are considered to have a potential correlation.

[0077] In one embodiment, the width of the timing correlation interval can be a preset fixed value; alternatively, the width of the timing correlation interval can also be determined based on the microarchitecture parameters of the master node agent, wherein the microarchitecture parameters can include at least one of the following: internal pipeline stages, arbitration latency, sniffing response timeout threshold, downstream storage access latency, and maximum waiting period for flow control credit return. This embodiment proposes a flexible and configurable timing correlation interval calibration mechanism, which defines the time window width by using either a preset fixed value or dynamic calculation based on the microarchitecture parameters of the master node agent. This is used to accurately define the time range of causally related transactions during transaction correlation matching, thereby adapting to hardware design scenarios with different performance characteristics and protocol constraints. The preset fixed value can be manually set by technicians based on experience or typical design specifications, and it can be configured as a fixed global variable in the simulation configuration script. For example, it can be uniformly set to 100 clock cycles or 50 nanoseconds, which is suitable for verification scenarios with low timing accuracy requirements or relatively simple architectures. The microarchitecture parameters are key indicators that can reflect the internal hardware behavior characteristics of the master node agent HA. These parameters can be extracted from chip design documents, register configuration files, or hardware description language (HDL) parameters. The internal pipeline stages refer to the number of logical stages required for HA to process a transaction; these are typically integers, with each additional stage usually corresponding to a one-clock-cycle delay. The arbitration latency is the waiting time incurred when multiple concurrent requests compete for resources at the HA entry point; it can be the maximum number of waiting cycles or an average latency statistic. The sniffing response timeout threshold is the maximum allowed time from issuing a sniffing request to receiving a response, as specified in the protocol; it can be directly mapped to the Timeout parameter in the protocol specification. The downstream storage access latency refers to the typical round-trip time (RTT) for HA to initiate a request to the memory controller and receive the returned data; it can be the sum of timing parameters such as tCL+tAL+tBL in the DRAM specification. The maximum waiting period for flow control credit return refers to the longest period during which the sender waits for the receiver to return credit values ​​in a credit-based flow control mechanism; it reflects the maximum stall time under backpressure conditions.

[0078] Take the verification scenario of a high-performance multi-core server chip as an example. In this scenario, the master node agent HA has a complex 16-stage pipeline structure and is connected to a high-latency DDR4 memory subsystem. If a fixed timing association interval (e.g., 50ns) is used, it may miss remote read transactions with large memory access latency (e.g., 200ns) but a causal relationship due to the narrow interval, leading to association failure. Conversely, if the fixed value is set too large (e.g., 500ns) to cover memory latency, it may lead to the incorrect association of other core transactions that are unrelated and happen to be close in time, generating a large number of false alarms. When adopting the dynamic calculation mode of this solution, the verification system first reads the HA microarchitecture configuration: 16 pipeline stages, a maximum arbitration latency of 8 cycles, a typical memory access latency of 120ns, and a sniffing timeout threshold of 300ns. Subsequently, the association matching engine dynamically calculates the interval width based on the type of transaction currently being processed. For example, for fast transactions involving local cache hits, the engine uses a smaller interval (e.g., 16*T_clk + 8*T_clk); while for transactions involving remote memory access, the engine automatically expands the interval to 120ns + Margin. In actual execution, when a write request and its corresponding data response are captured, the system calculates the time difference between them. If the time difference is 130ns, although it exceeds the fixed value of 50ns, it is within the dynamically calculated 150ns interval and is therefore correctly identified as a related transaction. This adaptive adjustment based on microarchitecture parameters ensures that the verification logic closely matches the actual physical characteristics of the hardware.

[0079] This embodiment addresses technical issues such as high false negative or missed detection rates due to improper time window settings in transaction association, and the lack of adaptability of verification schemes to different hardware architectures. By providing a dynamic calculation method based on microarchitecture parameters, the interval width can reflect the actual latency characteristics of the hardware (such as pipeline depth and memory latency) in real time, thereby significantly improving the accuracy of association matching and effectively avoiding logical errors caused by the inability of fixed windows to accommodate both fast and slow transactions. The scheme using preset fixed values ​​provides a simple configuration path. Since complex parameter extraction is not required in early prototype verification or simple module testing, it helps lower the threshold for setting up the verification environment and the initial configuration cost, thereby improving development efficiency. This dual mechanism enhances the versatility and robustness of the verification platform. Because the system can flexibly switch strategies according to the specific characteristics of the object under test, the same set of verification code can seamlessly adapt to master node agents of various microarchitectures, from low-power embedded kernels to high-performance server chips.

[0080] Besides using fixed values ​​or dynamic calculations based on microarchitecture parameters, an adaptive interval adjustment scheme based on historical data statistical learning can also be used for timing definition. For example, in the early stages of operation, the verification system can collect a certain number of known related transaction samples, statistically analyze the distribution characteristics of their timestamp differences (such as mean and standard deviation), and dynamically set the confidence interval (such as Mean+3σ) accordingly. This scheme can automatically adapt to the actual delay fluctuations of the chip under different load, temperature, or voltage conditions, optimizing matching accuracy without manual intervention, and is particularly suitable for long-term stability testing or scenarios heavily influenced by environmental factors. Alternatively, a variable-length window scheme based on protocol state machine event-driven mechanisms can also be used. For example, instead of pre-setting a fixed width, different timers are started according to the state machine node into which the transaction enters, until the expected next state event or timeout signal is received. This scheme can strictly adhere to the timing constraints defined by the protocol, fundamentally eliminating correlation deviations caused by estimation errors, ensuring that all related transactions meet the strict timing requirements of the protocol specification, and is suitable for certification-level verification scenarios with high protocol compliance requirements.

[0081] In one embodiment, a multi-level filtering mechanism can be used to divide the associated groups. For example, the target address can be used as the first matching key to filter at least one first-level candidate transaction set with the same target address; then, in each first-level candidate transaction set, the original transaction identifier can be used as the second matching key to filter at least one second-level candidate transaction set with the same original transaction identifier; then, in each second-level candidate transaction set, the opcode can be used as the third matching key to filter at least one third-level candidate transaction set with the same opcode or a semantic dependency relationship defined by the protocol; finally, in each third-level candidate transaction set, the global timestamp can be used as the fourth matching key to filter multiple transactions whose global timestamp differences are within the same temporal association interval, and these multiple transactions are divided into the same associated group. This embodiment, by performing four levels of filtering sequentially using the target address, original transaction identifier, opcode semantics, and global timestamp as matching keys, can efficiently and accurately identify associated transaction sets belonging to the same logical processing link from massive concurrent and out-of-order transactions.

[0082] The first matching key (target address) is a spatial dimension feature used to initially narrow down the search scope. Specifically, it can be a physical memory address or a cache line address. Since consistency protocols typically manage cache lines, this key value can be the high-order part of the address (Address Tag), allowing for quick location of all transactions accessing the same storage area through hash mapping or range tree indexing. The corresponding first-level candidate transaction set is a subset of transactions retained after the first-level filtering. This subset can be temporarily stored in memory using a dynamic array or linked list structure. While the transactions in this subset may share the same address, they may belong to different independent request streams. Furthermore, the second matching key (original transaction identifier) ​​is a unique sequence number generated by the master node proxy or requesting node that initiated the request. This could be the TxnID field in the protocol message header, used to distinguish different concurrent access requests to the same address, ensuring that only transactions originating from the same initial request and its derived responses are retained. The third-level matching key (opcode semantic dependency) is a logical relationship defined based on the protocol state machine. It can include not only cases where the opcodes are completely identical (e.g., ReadShared responding to ReadShared), but also combinations of dissimilar opcodes with causal relationships (e.g., WriteUnique triggering SnoopShared, or CleanShared triggering DataResp). Specifically, semantic dependencies can be evaluated based on a predefined state transition table or semantic dependency graph, allowing transactions with different opcodes but logically closely related to each other to be grouped together. The final fourth matching key (temporal association interval) is a time-dimensional constraint used to eliminate ambiguity. It compares the absolute value of the difference between the global timestamps of transactions, |δT| = |T_i-T_j|, with a preset threshold T_0. As mentioned earlier, this threshold can be dynamically calculated based on the microarchitectural parameters of the master node agent (e.g., pipeline depth, arbitration latency), ensuring that only transactions occurring within a reasonable physical latency range are considered associated.

[0083] Taking a typical cache conflict scenario in a multi-core processor cluster as an example, in this scenario, CPU Core 0 (RN1) initiates an exclusive write request (WriteUnique) to address 0x8000, while at the same time, CPU Core 1 (RN2) happens to hold a shared copy of that address and initiates a read request (ReadShared). First, the global transaction index of the verification system may contain tens of thousands of transaction records. When the multi-dimensional cross-transaction matching engine starts the association process, it first performs the first-level filtering: using address 0x8000 as the key, it quickly extracts all transactions involving that address from the full index, forming a first-level candidate set. At this time, this set may contain the write request from Core 0, the read request from Core 1, and residual data from previous accesses to that address by other cores. Next, it performs the second-level filtering: in the first-level candidate set, it searches for the original transaction identifier. Assuming the original ID of WriteUnique is Txn_A, the engine will filter out all transactions with the original ID Txn_A or its derived IDs (such as the Snoop ID generated internally by HA), forming a second-level candidate set. This step excludes the independent read request from Core 1 with the original ID Txn_B (unless they later interacted). Next, a third level of filtering is performed: checking the opcode semantics. The engine finds a WriteUnique request and a SnoopShared request issued by HA in the second-level candidate set. According to the CHI protocol definition, WriteUnique necessarily triggers SnoopShared, and the two have a strong semantic dependency; therefore, despite their different opcodes, they are retained in the third-level candidate set. Finally, a fourth level of filtering is performed: comparing timestamps. Assuming the timestamp of WriteUnique is 100ns and the timestamp of SnoopShared is 105ns, the difference is 5ns. If the preset time-series association interval is [0, 20ns], then 5ns falls within the interval, and the two are determined to be associated. Ultimately, these two transactions are grouped into the same association group, and a pointer link is established. Through this progressive filtering, the system avoids incorrectly associating unrelated transactions with the same address but different IDs, or transactions with the same ID but a large time span, ensuring the accuracy of link reconstruction.

[0084] This embodiment addresses the technical challenges of high computational complexity, high false alarm rate, and difficulty in handling protocol semantic dependencies when performing transaction association globally. By introducing a multi-level short-circuit mechanism with the target address as the primary filtering condition, the data scale to be processed in subsequent matching steps is significantly reduced, thereby significantly lowering the algorithm's time complexity. This allows the system to complete the association judgment of massive concurrent transactions within nanoseconds, improving real-time processing capabilities. Secondly, by combining the semantic dependencies of the original transaction identifier and opcode for joint matching, it utilizes protocol-level logical constraints rather than relying solely on temporal proximity, effectively eliminating false associations caused by bus contention or latency jitter, and improving the accuracy and robustness of transaction grouping. Furthermore, by introducing a timing association interval based on microarchitecture parameters, it can flexibly adapt to master node agents of different frequencies and pipeline depths by considering the actual physical latency characteristics of the hardware, avoiding the poor adaptability problem caused by fixed time windows, and enhancing the universality and scalability of the verification scheme across different chip designs.

[0085] Figure 4 This is a flowchart illustrating the workflow of a multi-dimensional cross-transaction matching engine according to an embodiment of the present invention. This process, through a four-level serial short-circuit filtering mechanism, can accurately identify related transactions belonging to the same logical processing link from a massive number of concurrent and out-of-order transactions. The following describes each filtering step: Step S201: Transaction Input and Classification The matching engine first receives the raw data stream from the global port capture device and preprocesses and categorizes the parsed key transaction information. For example, based on the parsed transaction type (such as Request, Response, Snop, or Data), transactions can be stored in corresponding logical queues (such as ReqQueue, RspQueue, SnpQueue, DataQueue, etc.). This step establishes a structured foundation for subsequent efficient retrieval, ensuring that different types of sub-transactions are stored in isolation, avoiding the performance overhead of full scans.

[0086] Next, steps S202-S205 are used to perform multi-dimensional step-by-step matching of transactions (i.e., filtering step-by-step according to different filtering conditions): Step S202: First-dimensional matching based on target address consistency (i.e., primary key filtering) The matching engine initiates the first level of filtering, using the target address Addr as the first matching key. The system extracts all transactions involving the same physical memory address or cache line address from the global transaction index, forming a first-level candidate transaction set. Since consistency protocols typically manage data on a cache line basis, the address is the most important spatial dimension feature for determining whether transactions are related.

[0087] This step can employ a short-circuit optimization strategy: if the current transaction does not match other transactions in the address dimension, it can be directly determined as unrelated, skipping all subsequent matching steps, thereby significantly narrowing the search scope.

[0088] Step S203: Second-dimensional matching based on the original transaction identifier The matching engine performs a second-level filtering process in each primary candidate set filtered by address, using the original transaction identifier OrigTxnID as the second matching key. By comparing the original IDs of the candidate transactions, transactions originating from the same initial request or its derived responses are filtered out, forming a secondary candidate transaction set. This step aims to distinguish different concurrent access flows to the same address, ensuring that only transactions with a clear causal relationship are retained, and excluding irrelevant parallel access interference.

[0089] Step S204: Third-dimensional matching based on opcode Next, the matching engine performs a third-level filtering in each secondary candidate set, using the opcode and its semantic dependencies as the third matching key. At this point, it can not only check whether the opcodes are completely identical (e.g., ReadShared to ReadShared), but also determine whether there is a logical causal relationship between different opcodes based on a predefined protocol state machine or semantic dependency table (e.g., WriteUnique triggers SnoopShared, or CleanShared triggers DataResp, etc.).

[0090] This process can retain transactions with protocol-level logical dependencies in the three-level candidate set, and further eliminate transactions that are related by ID but have no logical interaction.

[0091] Step S205: Fourth-dimensional matching based on global timestamp differences Finally, the matching engine can perform a fourth-level filtering in each of the three-level candidate sets, using the global timestamp difference as the fourth matching key. For example, it can calculate the absolute timestamp difference |ΔT| between every two transactions in the set and determine whether this difference is less than the preset dynamic time-series correlation interval threshold T_window, i.e., whether it satisfies |T1-T2|. <T_window。

[0092] This threshold can be dynamically adjusted based on HA's microarchitecture parameters (such as pipeline stages and arbitration latency). If the time difference between two transactions is within a reasonable physical latency range, they are considered to have a real-time causal relationship. This step can eliminate false time proximity misjudgments caused by bus contention or long latency.

[0093] In this process, after each level of matching is successful, the process proceeds to the next level of matching; if any level of matching fails, the process proceeds to step S206 for anomaly marking. In fact, if any level of matching fails, the process can directly proceed to step S206 for anomaly marking without continuing to match the remaining dimensions.

[0094] In step S206, if any level of matching fails (i.e., no association group exists), it indicates that there is no valid association between transactions. At this time, the matching engine can mark the exception, such as recording the reason for the mismatch (e.g., address conflict, ID mismatch, semantic irrelevance, or timeout), and treat these transactions as independent events or potential single points of failure, and no longer establish intra-group links, thereby ensuring the purity and accuracy of the association link.

[0095] Steps S206-S208: Result Determination and Output If all four levels of matching pass (i.e., at least one associated group exists), it indicates that the group of transactions satisfies all association conditions for address, ID, semantics, and time sequence. At this point, the matching engine proceeds to step S206 to establish cross-transaction associations, such as updating the association pointer list of these transaction entries in the Global Transaction Index (GTT) so that they point to each other, forming a complete topological link. Finally, step S208 is executed to output the association results, such as marking the associated group as valid for use by the subsequent time sequence reassembly module.

[0096] Of course, besides the four-level serial short-circuit filtering scheme, a parallel query scheme based on multi-dimensional spatial indexes (such as R-Tree or KD-Tree) can also be used for transaction association. For example, each transaction can be mapped to a multi-dimensional vector (address, ID, time, opcode encoding) to build a high-dimensional index structure, and a range query can be used to retrieve the set of transactions that meet all conditions at once. This scheme can leverage the efficient pruning capability of spatial indexes to maintain stable query performance under extremely high concurrency, avoid the load imbalance problem that may be caused by serial filtering, and support more complex non-rectangular query regions. Alternatively, an event-driven rule engine matching scheme can also be used. For example, a set of assertion rules based on pattern matching can be defined (such as "when WriteUnique occurs, listen for SnoopShared within the next 20ns"), and the transaction stream can be input into the rule engine for real-time matching. This scheme can intuitively express complex protocol timing constraints, making it easy for technical personnel to directly write and debug association rules. It has extremely high flexibility and readability, and is particularly suitable for verification scenarios with frequent protocol changes or high customization, enabling rapid response to new association requirements without modifying the underlying algorithm code.

[0097] Step 308: For each associated group recorded in the global transaction index structure, obtain the global timestamp of each associated transaction in the group from the global transaction index structure, and reassemble the associated transactions in the group into a complete processing link according to the order of the global timestamps, so as to realize the time sequence restoration of out-of-order requests.

[0098] This step employs a link reorganization mechanism based on global timestamp sorting. By sorting transactions within the associated group in ascending order and disambiguating them, it restores a complete and consistent interaction trajectory that conforms to the physical execution order. The restored complete processing link refers to a sequence of transactions arranged according to the actual hardware execution order, encompassing all stages from request initiation to final completion. This link visually demonstrates the entire protocol interaction process and supports anomaly detection. This link can take the form of an ordered array or a singly linked list, for example, a timeline sequence of [WriteReq -> SnoopShared -> SnoopResp -> DataResp]. Time-series restoration refers to the process of rearranging out-of-order transactions to conform to causal relationships and physical latency patterns. This eliminates time illusions caused by sampling parallelism or transmission delays, establishing a unique execution view. This process can be implemented using a stable sorting algorithm combined with secondary key disambiguation. For example, it can first sort by global timestamp in ascending order; if timestamps are the same, it can then perform secondary sorting by source port number value to break ties.

[0099] In this step, the system traverses each associated group, extracting the GlobalTxnID and its corresponding timestamp for all transactions within the group. Using quicksort or mergesort algorithms, the transactions are sorted with the timestamp as the primary key and the port number as the secondary key. After sorting, the transactions are linked sequentially to form a complete chain from beginning to end. This step is the endpoint of the process flow; it transforms the abstract association into a concrete time series, directly outputting the final result that can be used for manual review or automated assertion checks. It allows technical personnel to clearly see the true timing of arbitration, sniffing, and response within HA, like watching a slow-motion replay, facilitating the precise location of hidden bugs such as deadlocks, timeouts, or state machine transition errors.

[0100] As can be seen from the above embodiments, the verification system proposed in this invention and the on-chip transaction verification scheme implemented by the system can synchronously collect the original transaction data of all ports by setting a unified observation point at the ports of the master node agent facing multiple request nodes, breaking the information silos of traditional single-port monitoring. By assigning a globally unique global transaction identifier to each transaction and constructing a global transaction index structure, centralized management of cross-port transaction data is achieved. Furthermore, based on multi-dimensional conditions such as target address, original transaction identifier, opcode semantic dependency, and temporal correlation interval, scattered and disordered sub-transactions are accurately divided into the same association group, and intra-group correlation relationships are established. Finally, the transactions within the association group are reassembled temporally based on the global timestamp to restore the complete physical processing link.

[0101] Understandably, by establishing a globally unified indexing and association mechanism, the system effectively overcomes transaction out-of-order issues caused by internal arbitration in HA, pipeline delays, and cross-port dependencies, achieving automated restoration from fragmented logs to the complete transaction chain. This not only significantly improves the coverage of protocol consistency verification but also enables technical personnel to intuitively track the entire lifecycle of any logical transaction, quickly pinpoint the root cause of protocol violations such as lost responses, deadlocks, or abnormal states, and significantly improve the efficiency and accuracy of SoC verification.

[0102] In one embodiment, when reorganizing transactions according to global timestamps, the related transactions within the group can be initially sorted in ascending order of the global timestamps. Then, it is checked whether multiple related transactions with the same global timestamp exist after sorting. If not, reorganization can be performed directly based on the initial sorting result; otherwise, if they exist, a secondary sort can be performed based on the numerical value of the source port number to eliminate timing ambiguity, and then reorganization can be performed based on the secondary sorting result. This is a timing disambiguation reorganization mechanism based on dual sorting of global timestamps and source port numbers. By first performing an initial sort based on ascending global timestamps, and then performing a secondary sort using the numerical value of the source port number when timestamps are the same, it can effectively solve the timestamp conflict problem caused by clock granularity limitations in high-concurrency scenarios, thereby establishing a unique physical execution order for transactions within the related group to restore the complete processing chain.

[0103] The global timestamp refers to a logical or physical time value maintained uniformly by the verification system, reflecting the moment a transaction occurs. For example, the current simulation time of the simulator, the number of cycles generated by the hardware counter, or a high-precision nanosecond-level clock signal can be used as the global timestamp. These timestamps typically have a fixed resolution (e.g., 1 ns or 1 clock cycle). Due to hardware parallelism, multiple transactions may be sampled on the same clock edge, resulting in identical timestamps. The "preliminary sorting" refers to the first round of linear arrangement of all transactions within the associated group according to the time dimension. Common algorithms such as QuickSort, Merge Sort, or HeapSort can be used to roughly organize transactions in chronological order. The source port number refers to the unique physical identifier or logical channel number of the requesting node (RN) initiating the transaction in the on-chip interconnect network. It can be implemented using an integer type port ID, which is usually fixedly assigned during the chip design phase and has a clear numerical relationship. The term "secondary sorting" refers to a second round of stable sorting using a backup sorting key (source port number) when the primary sorting key (timestamp) is equal. This can be achieved by employing a stable sorting algorithm or adding secondary judgment conditions to the comparison function, ensuring that the final sequence is determined based on port priority or physical layout order when the time sequence cannot be distinguished. The term "temporal ambiguity" refers to a state where multiple transactions overlap on the timeline due to insufficient sampling precision or simultaneous parallel events, making it impossible to directly determine their causality or execution order. By introducing the deterministic attribute of the port number, this ambiguity can be transformed into a definite total order relationship.

[0104] Taking the dense interaction scenario where multi-core processors concurrently access shared storage resources in the same clock cycle as an example, in this scenario, assume that CPU Core 0 (corresponding to source port number Port=1) and CPU Core 2 (corresponding to source port number Port=3) respectively send read requests for different addresses to the host agent HA at the same simulation time T=1000ns, and HA returns the corresponding response data at the same time. After the multi-dimensional cross-transaction matching engine divides these two requests and their responses into respective association groups, it is necessary to reconstruct the link to analyze protocol compliance. First, the system extracts all transactions in the association group, and finds that the global timestamps of Request A (from Port 1) and Request B (from Port 2, assuming another core) are both 1000ns. If sorting only relies on timestamps, the order of these two transactions is undetermined, which may cause the reconstructed link to violate the arbitration priority or deadlock detection logic specified by the protocol. At this time, the secondary sorting logic is activated: compare the source port numbers, Port 1 < Port 2. Therefore, the system ranks the transaction from Port 1 before the transaction from Port 2. In a more complex snooping scenario, if HA sends snooping requests to Port 1 and Port 3 simultaneously at T=1005ns, and both responses arrive simultaneously at T=1010ns, the internal logic sequence of HA processing snooping responses can be clearly defined through sorting by port number (Port 1 precedes Port 3). This sorting result not only conforms to the fixed-priority strategy usually adopted by hardware arbiters (e.g., lower port number priority), but also provides a definite input sequence for subsequent deadlock detection, avoiding false positives or false negatives caused by random sorting. Finally, the reconstructed link presents a clear timing sequence of "Port 1 request → Port 1 response → Port 2 request → Port 2 response", which truly reflects the execution trajectory inside the hardware.

[0105] This embodiment addresses technical issues such as uncertain parallel transaction order due to limited timestamp resolution, non-unique link reassembly results, and resulting protocol verification misjudgments. By introducing the source port number as a secondary sorting key, a deterministic total order relationship is established, eliminating the randomness caused by timestamp collisions. This ensures the consistency of the transaction link order generated in each simulation run, improving the repeatability of verification results and the traceability of debugging. Secondly, this sorting rule aligns with the actual arbitration logic of the hardware. Since many on-chip interconnect arbitrators employ static priority or polling mechanisms based on port numbers, the reassembled software links more closely approximate the actual physical execution order of the hardware, enhancing the accuracy of anomaly localization. Furthermore, this mechanism is simple to implement and has extremely low overhead. It only requires adding an integer comparison operation to the sorting comparison function, effectively resolving timing ambiguities in high-concurrency scenarios without significantly increasing computational complexity, thus ensuring the stability and efficiency of the verification system under large-scale stress testing.

[0106] In addition to secondary sorting schemes based on source port number values, timing disambiguation can also be performed using secondary sorting schemes based on transaction type priority. For example, a transaction type priority table can be predefined, specifying that response transactions take precedence over request transactions, or snoop responses take precedence over data responses. Based on this, when timestamps are the same, they can be sorted according to the preset type priority. This scheme can more accurately reflect the logical constraints in the consistency protocol that "responses must be processed before new requests" or "control flow takes precedence over data flow," helping to detect hidden errors that violate protocol timing rules earlier. Alternatively, secondary sorting schemes based on physical distance or topology level can also be used. For example, based on the hop count between the requesting node and the master node agent or the physical wiring length, node transactions that are closer or have lower latency are prioritized. This scheme can more finely simulate the differences in signal propagation delay in the interconnect network, is suitable for verifying high-speed interconnect architectures that are extremely sensitive to timing, and can further narrow the gap between the software model and the actual hardware behavior, improving the high fidelity of timing reconstruction.

[0107] In one embodiment, based on the complete processing link, protocol anomaly events (such as response loss, transaction timeout, and / or deadlock) can also be detected. Then, in response to the detection of any protocol anomaly event, the link node where the anomaly occurred is located in the complete processing link, and a verification log for that link node is generated. This verification log may at least contain the anomaly type and location. This is a protocol anomaly detection and precise location mechanism based on the complete processing link. By monitoring anomaly events such as response loss, transaction timeout, and deadlock, and locking the faulty node in the reconstructed link and generating a verification log containing the anomaly type and location when an anomaly is detected, it enables rapid tracing and automated debugging from macroscopic phenomena to microscopic root causes.

[0108] The protocol anomalies refer to a set of states that violate hardware consistency protocol specifications or the expected behavior of the system. These can be detected using methods such as state machine violation flags, counter overflows, or timeout timer trigger signals. Response loss occurs when no corresponding response message is received within a preset time after a request is initiated. This can be detected by checking if there are transactions with a response type matching the global transaction identifier within the associated group. Transaction timeout occurs when the time elapsed from transaction initiation to completion exceeds the maximum allowable delay specified by the protocol (e.g., Snoop Response Timeout). This can be detected by calculating the difference in global timestamps between the first and last transactions in the chain and comparing it with a threshold. Deadlock occurs when two or more transactions are waiting for each other to release resources, causing the system to stagnate. This can be detected by constructing a transaction dependency graph and checking for closed cycles within the graph. Furthermore, the complete processing chain described in this embodiment refers to an ordered sequence of all related sub-transactions, including requests, sniffing, responses, and data, formed after time-series reorganization. This sequence can be maintained in memory using a doubly linked list or array structure, serving as the context for anomaly analysis. The link node refers to each independent transaction entry in the link or its corresponding hardware logic unit (such as a send / receive buffer for a specific port, an internal HA arbiter, a directory entry, etc.), which can be uniquely identified by the transaction's source / destination port number, opcode, and internal status field. The verification log is a structured data file used to record detailed exception information, such as JSON, XML, or a custom binary format file. For example, the content of this file may include exception type enumeration values, the GlobalTxnID of the transaction that caused the exception, a timestamp, and a descriptive string pointing to the faulty hardware module.

[0109] Consider a scenario where a multi-core SoC experiences a system hang under high load stress testing. In this scenario, CPU Core 0 initiates an exclusive write request for shared data, while CPU Core 1 simultaneously holds a shared copy of that data and initiates a read request. First, the multi-dimensional cross-transaction matching engine reassembles these two requests and their subsequent interactions into a complete processing chain. Suppose that due to a bug in the HA's internal directory state machine, after sending a sniffing request to Core 1, it fails to correctly update its internal state to wait for Core 1's response, instead mistakenly assuming the transaction is complete and closing the listening window. At this point, the verification system's anomaly detection module traverses this chain and finds that Core 0's request exists, and the Snoop sent by HA also exists, but the SnoopResp returned by Core 1 is missing, and the current simulation time has far exceeded the sniffing response timeout threshold specified by the protocol (e.g., 300ns). Therefore, the module determines that a "response loss" and "transaction timeout" anomaly has occurred. Next, the last valid node in the logic analysis chain was located, revealing that the HA state machine, after issuing a Snoop, did not enter the Wait_Snoop_Resp state but instead transitioned to the Idle state. Therefore, the system located the anomaly to the "HA internal directory state machine" and marked the anomaly type as "STATE_MACHINE_JUMP_ERROR / RESPONSE_LOST". Finally, the system generated a verification log recording: "[ERROR] TxnID=0xA5,Type=RESPONSE_LOST,Location=HA_Directory_SM,Time=450ns, Suggestion=Check State Transition Logic for Snoop_Wait". Technical personnel only need to review this log to directly locate and repair the state machine transition logic in the RTL code, without needing to manually search through massive amounts of waveform files.

[0110] This embodiment addresses technical challenges such as difficulty in detecting protocol anomalies, difficulty in locating root causes of faults, and long debugging cycles. Detection based on the complete processing chain, by understanding the full lifecycle context of transactions, accurately distinguishes between genuine protocol violations and mere signal noise, significantly reducing false alarm rates and improving the reliability of anomaly detection. Secondly, by precisely locating the anomaly node within the chain, directly identifying the specific hardware module or logical step where the fault occurred, it avoids blindly troubleshooting across the entire chip, greatly shortening the Mean Time To Repair (MTTR) from problem discovery to root cause location. Furthermore, the automatic generation of verification logs containing key information standardizes and structures debugging information, allowing anomaly records to be parsed and archived by automated tools. This facilitates the establishment of a fault knowledge base, supports rapid comparison and historical problem tracking in subsequent regression testing, and improves the automation level and efficiency of the overall verification process.

[0111] In addition, a real-time monitoring scheme based on formal verification attributes (Assertions) can be used for anomaly capture. For example, a series of SystemVerilog Assertions (SVAs) can be embedded in the verification platform, defining attributes such as "if a Request is issued, a Response must be received within N cycles," triggering an interruption if an attribute fails. This scheme can leverage the powerful formal proof capabilities of EDA tools to discover potential deadlock or livelock paths in the early stages of simulation or even the static phase, providing mathematical-level completeness guarantees, and is particularly suitable for critical path verification with high security requirements. Alternatively, a behavior baseline deviation detection scheme based on machine learning can be used. For example, transaction link characteristics (such as latency distribution, throughput, and concurrency) under normal simulation operation can be collected, and an unsupervised learning model (such as an isolated forest or autoencoder) can be trained to calculate the deviation of the current link from the baseline in real time during subsequent runs. This scheme can discover "soft faults" or performance degradation problems (such as rare race conditions or atypical latency spikes) that are not explicitly defined as protocol errors but exhibit abnormal behavior, expanding the verification coverage boundary and being suitable for exploratory testing and long-term reliability assessment scenarios.

[0112] In the previous embodiment, when generating verification logs for the link node, error correction suggestion information matching the exception type can be determined based on the exception type of any protocol exception event, and verification logs containing the error correction suggestion information can be generated. The error correction suggestion information may include at least one of the following: suggested investigation directions for internal sub-modules of the master node agent, sniffing filter state machine verification, storage subsystem path checking, and flow control credit return mechanism checking. This is an intelligent error correction suggestion generation mechanism based on exception type mapping. By querying a preset knowledge base for matching investigation directions based on the detected protocol exception event type, and writing structured data containing suggestion information such as specific sub-modules, state machine verification, or path checking into the verification log, it can assist technicians in quickly locating the root cause of hardware design defects and shortening the debugging cycle.

[0113] The error correction suggestions refer to a set of guiding debugging clues provided for specific protocol violations. These can be string arrays, enumeration type mapping tables, or JSON objects, and the content can cover hardware logic module names, signal paths, and possible causes of failure. The internal sub-modules of the master node agent refer to logical units within HA responsible for specific functions, such as arbiters, directory managers, data buffers, or routing logic. They can be identified by module-level path strings (e.g., top.ha_core.dir_ctrl). The sniffing filter state machine verification direction refers to troubleshooting guidance for anomalies in consistent directory state transitions. This can include suggested state nodes to check (e.g., S_WAIT_SNOOP_RESP), condition signals triggering transitions (e.g., SnoopAck_Valid), and expected next states, typically presented as "checking if the state machine is stuck in a transaction information state." The storage subsystem path inspection direction refers to troubleshooting suggestions for excessive memory access latency or data return errors. This may involve checks on memory controller interface signals, DRAM timing parameter configurations, or physical link integrity, such as "checking for backpressure blocking in the data path from MC to PHY." The flow control credit return mechanism inspection direction refers to troubleshooting suggestions for transaction stalls or deadlocks caused by flow control. This may include checking whether the credit counter has reached zero, whether the credit return signal is lost or delayed, and the handshake synchronization status between the sender and receiver. The preset error correction suggestion library refers to a data structure that stores the mapping relationship between exception types and suggestion information. This can be implemented using a hash table, database table, or hard-coded switch-case logic. For example, the key can be the exception type (e.g., ERR_TIMEOUT), and the value can be the corresponding list of suggestion information.

[0114] Take, for example, a scenario where a transaction timeout occurs during a high-concurrency mixed read / write test on a multi-core processor. In this scenario, the verification system detects that a write request (WriteUnique) has not received a completion response (Comp) after more than 500ns, and determines it as a "transaction timeout" exception. First, the exception detection module extracts the key characteristics of the transaction: the opcode is WriteUnique, the target address is located in the DDR region, and the last known state is "waiting for data return". Next, the log generation module queries the preset error correction suggestion library. Since the exception type is "TIMEOUT_DATA_RETURN" and involves downstream storage access, the matching suggestion information in the library includes: "1. Check if the master node agent's internal data buffer is full, causing blockage; 2. Check the storage subsystem path to confirm whether the memory controller (MC) is causing excessive access latency due to DRAM refresh or row conflicts; 3. Check the flow control credit return mechanism to confirm whether the credit signal from MC to HA is returned in a timely manner." Subsequently, the system packages these suggestion information with the exception timestamp, GlobalTxnID, and link snapshot to generate a detailed verification log entry. When reviewing logs, technicians no longer need to analyze waveforms from scratch. Instead, they can directly follow the suggestion to "check the credit signal from MC to HA," quickly discovering that a rare boundary condition is causing the credit counter to not increment correctly, allowing for rapid bug fixing. In another scenario, if a "SNOOP_NO_RESPONSE" exception occurs, the suggestion library might point to "sniff filter state machine verification direction," indicating whether HA has incorrectly skipped the Snoop Resp waiting state and directly entered the idle state. This targeted suggestion transforms the debugging process from "finding a needle in a haystack" to "following the clues."

[0115] This embodiment addresses technical issues such as insufficient anomaly log information, reliance on personal experience for debugging, and low efficiency in fault reproduction and analysis. By associating anomaly types with specific hardware troubleshooting directions, it provides clear debugging entry points (such as specific submodules or signal paths), significantly reducing the cognitive load and search space for technicians and drastically shortening the time-to-response time (MTTR). Secondly, the built-in error correction suggestion library digitizes expert experience, solidifying the diagnostic logic for various protocol errors for technicians. This allows even junior technicians to receive high-quality debugging guidance, improving the overall verification capabilities and knowledge reuse rate of the technical team. Furthermore, this structured suggestion information facilitates automated script parsing and processing. Due to the standardized log format, it supports the construction of automated regression test analysis reporting systems, facilitating the statistical analysis of frequently failing modules and common error types, providing quantitative data support for hardware architecture optimization and design quality assessment.

[0116] In addition to the query scheme based on a statically preset error correction suggestion library, log enhancement can also be achieved using a dynamic context-aware inference engine to generate suggestion schemes. For example, the system can not only record the anomaly type, but also combine the complete context of the current link (such as the number of concurrent transactions, cache hit rate, and bus load rate) to dynamically deduce the most likely root cause using a rule engine or lightweight decision tree. This scheme can provide more personalized and accurate troubleshooting suggestions, especially when dealing with complex anomalies caused by multiple coupled factors. It can eliminate irrelevant interference items and directly point to the most suspicious hardware module, improving the hit rate of suggestions. Alternatively, a historical log mining scheme based on natural language processing (NLP) can also be used. For example, the system can maintain a knowledge graph containing historical bug reports and their solutions. When a new anomaly occurs, it can find similar historical failure cases through semantic similarity matching and recommend the repair solutions at that time as suggestions. This scheme can continuously evolve using accumulated project data, covering new or rare error patterns not defined in the initial suggestion library, and is particularly suitable for large-scale chip projects with long-term iterations.

[0117] In one embodiment, users can also be allowed to automatically retrieve / filter logs. For example, a filtering instruction (such as transaction type, physical port number, and / or transaction status) can be received from the user, and then, based on the filtering instruction, target log entries that match the filtering instruction can be filtered and output from the full verification log. This embodiment proposes a multi-dimensional conditional filtering log interaction mechanism that, by receiving user instructions containing transaction type, physical port number, and transaction status, accurately filters target entries from the full verification log, enabling rapid focusing on key debugging information in massive simulation data.

[0118] The filtering instruction is a set of parameters issued by the user or automated script to limit the scope of log retrieval. These parameters can be command-line arguments, graphical user interface (GUI) form inputs, or API call parameters, and can support logical combinations (such as AND / OR). The "transaction status" refers to the lifecycle status or final result of a transaction at the current moment, such as "Pending," "Completed," "Error," or "Timeout." The transaction status can be determined by querying the Status Flag or associated exception flags in the log. The full verification log refers to the original dataset recording all observed transactions and their associated information, which can be stored as a database table, a large text file (such as CSV / JSON), or a list of objects in memory. The target log entry refers to the subset retained after matching the filtering conditions. It can be a single transaction record or all related transactions in the complete processing chain associated with that record.

[0119] Additionally, when outputting the target log entries, entries related to the aforementioned protocol anomalies can be highlighted, such as by changing the font color (e.g., red highlighting), bolding, adding background color, or appending special markers (e.g., [!!!]) to the terminal. This visual enhancement of specific log entries improves readability and draws user attention to potential fault points.

[0120] Take the scenario of analyzing deadlock issues after large-scale multi-core SoC regression testing as an example. In this scenario, a complete regression test may generate millions of transaction logs, and directly browsing them is like finding a needle in a haystack. First, the technician enters the filtering command in the debugging terminal or GUI interface: Filter: Type=Write, Port=Core_3, Status=Timeout. The log processing module of the verification system receives this command and traverses the entire verification log database. It first filters out all transactions with the opcode "Write", then further filters the records with the source port number "Core_3" among these transactions, and finally checks the status flags of these records, keeping only the entries marked "Timeout". Assume that the filtering result points to a write request with GlobalTxnID 0x8899. The aforementioned embodiment has established a complete link and generated error correction suggestions, so the system can not only output this timed-out write request log, but also automatically associate and output other members in this link, such as the Snoop request issued by HA, the Snoop responses of other cores, and the final missing data return packet. To help users quickly identify problems, the system highlights all log entries in the complete timeout exception chain during output. For example, it adds an ">>ERROR LINK<<" marker before the text log, or renders the entire chain's timeline view with a red background in the GUI. Technical personnel can immediately see that although Core_3 issued a request, after HA issued a Snoop, although Core_1's response arrived, the HA internal state machine did not transition correctly, causing subsequent processes to stall. This precise focus, from millions of data points to a single abnormal chain, greatly simplifies the analysis process.

[0121] This embodiment of the solution addresses technical challenges such as information overload caused by massive amounts of verification log data, time-consuming and labor-intensive manual investigation, and the tendency for critical anomalies to be overlooked. By providing multi-dimensional filtering capabilities based on transaction type, port, and status, it allows users to narrow down their search scope according to specific areas of suspicion, significantly reducing the scale of data requiring manual review and shortening debugging time from hours to minutes or even seconds. Secondly, by automatically linking and highlighting the complete processing chain containing protocol anomalies, it integrates scattered and isolated error signals into a visually coherent whole with causal relationships. This helps technicians intuitively understand the context of the fault occurrence, avoiding the risk of misjudging the root cause by focusing on only a partial view, and improving the accuracy of debugging. Furthermore, this interactive filtering mechanism supports iterative debugging. Users can further refine conditions based on the initial screening results (such as adding time window restrictions), thereby forming an efficient closed loop of "hypothesis-verification-re-filtering," improving the human-computer collaboration experience and overall debugging efficiency of the transaction verification platform. It is particularly suitable for the intensive bug fixing phase in the later stages of complex chip development.

[0122] Of course, a smart filtering scheme based on Natural Language Queries (NLQ) can also be used for log retrieval. For example, if a user enters "display recent deadlock-related transactions on Core 2", the system can use NLP technology to parse the semantics and automatically convert it into corresponding structured query conditions (Port=Core_2, Status=Deadlock / Lockup, Time=Recent). This scheme lowers the barrier to entry, eliminating the need for users to remember complex field names and syntax, allowing even non-expert technical personnel to efficiently obtain the required information. It also supports fuzzy queries, enabling the capture of undefined but semantically similar anomaly patterns. Alternatively, a dynamic sliding filter scheme based on time windows can be used. For example, instead of specifying fixed transaction attributes, a time point or event trigger point can be specified (such as "within 10ms after reset" or "when the first cache miss occurs"). The system automatically extracts all relevant transaction logs before and after that time window. This scheme can completely preserve the on-site environmental data before and after the anomaly, facilitating the analysis of sporadic failures caused by the cumulative effects of previous events, such as resource exhaustion or race conditions.

[0123] Figure 5 This is a schematic diagram illustrating a full-link log generation sequence according to an embodiment of the present invention. The diagram shows the complete interaction sequence of a typical "ReadUnique" transaction in a multi-core consistency protocol (such as ARM CHI / ACE) scenario, between the requesting node RN1, the master node proxy HA, and the requesting node RN2 holding the data (in practice, it can be any two RNs connected by HA; this embodiment only uses RN1 and RN2 as examples for illustrative purposes). The complete steps are as follows: Step S501: RN1 initiates a read exclusive request At time T0, requesting node RN1 sends a ReadUnique request to the master node agent HA. This request indicates that RN1 wishes to obtain exclusive state access to a specific memory address in order to perform write operations or ensure data consistency. After receiving this request, HA can query its internal consistency directory.

[0124] Step S502: HA triggers sniffing and hits (i.e., SF Hit).

[0125] Step S503: HA forwards data to RN2.

[0126] At time T0+δ1, HA determines, based on its consistent directory state, that the data at that address is currently held by RN2 (and its state may be Shared or Dirty). Therefore, it can send a SnpUnique request to RN2. This request has two functions: first, it requests RN2 to invalidate its local cache line; second, if RN2 holds dirty data, it requests RN2 to directly return the data to HA or RN1.

[0127] Step S504: RN2 responds to sniffing and sends back data. After receiving a sniffing request, RN2 performs an invalidation operation on its local cache line and packages the required data along with an acknowledgment signal (Ack). At time T0+δ1+δ2, it sends this data back to HA via a SnpRespData_I (sniff response data - invalidation) message. This step completes the transfer of data ownership and the synchronization of cache state.

[0128] Step S505: HA completes the transaction and sends back the final response. After receiving the data and acknowledgment from RN2, HA needs to update its internal directory state and send a CompData_UC response to the initial requester RN1 at time T0+δ1+δ2+δ3. This marks the end of the entire ReadUnique transaction, and RN1 now has exclusive control over the data block.

[0129] Figure 2 The complete process shown has a total end-to-end processing latency of T0+δ1+δ2+δ3+δ4. Furthermore, since RN2 has already returned the data, HA does not need to access the downstream storage subsystem again, demonstrating the efficiency of cache consistency.

[0130] Depend on Figure 2As shown in the complete process, the verification system can capture four events scattered across different nodes and at different times, and reassemble them into a logically coherent link through global timestamps and correlation algorithms. This solves the problem of "seeing only the part, not the whole" in traditional monitoring. Moreover, by recording the timestamps of each stage (δ1, δ2, δ3, δ4, etc.), the verification system can accurately calculate end-to-end latency. If a certain δ value increases abnormally, the system can immediately locate the bottleneck in HA arbitration, network transmission, or RN2 processing. If δ2 is found to be too large, it indicates that RN2 response is slow; if S504 is missing or S505 times out, it can accurately determine "response loss" or "deadlock," and point out that the fault occurs between HA and RN2. In addition, this process also reflects complex protocol semantic dependencies (ReadUnique→SnpUnique→SnpRespData→CompData). The multi-dimensional matching engine of this solution can identify such cross-node causal chains. Even if these packets arrive at the verification system out of order on the physical line, they can be correctly correlated through semantic and timing windows, ensuring the accuracy of protocol compliance checks.

[0131] Figure 6 This is a schematic structural diagram of an electronic device according to an embodiment of the present invention. Please refer to it. Figure 6 At the hardware level, the device includes a processor 601, a network interface 602, memory 603, non-volatile memory 604, and an internal bus 605, and may also include other hardware required for business operations. One or more embodiments of the present invention can be implemented in software, for example, the processor 601 reads the corresponding computer program from the non-volatile memory 604 into memory 603 and then runs it. Of course, in addition to software implementation, one or more embodiments of the present invention do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0132] Figure 7 This is a block diagram illustrating an on-chip transaction verification device according to an embodiment of the present invention. Please refer to... Figure 7 This device can be applied to, for example Figure 6 The device shown is used to implement the technical solution described in this invention. This device is applied to a master node agent in an on-chip system. The master node agent manages consistency transactions between multiple upstream requesting nodes and a downstream storage subsystem. The master node agent has a unified observation point set up at the port facing the multiple requesting nodes. The device includes: The observation unit 701 is used to synchronously collect transaction information of each transaction entering the master node agent through the unified observation point, wherein the key transaction information of each transaction includes at least the original transaction identifier, source port number, target address, opcode and global timestamp. The archive unit 702 is used to assign a global transaction identifier to each transaction and write the key transaction information of each transaction into the global transaction index structure using the global transaction identifier as an index. The association unit 703 is used to divide multiple transactions that meet preset association conditions into the same association group according to the key transaction information, and to establish the association relationship between each associated transaction in each group in the global transaction index structure; wherein, the preset association conditions include: the same target address, the same original transaction identifier, the same opcode or the existence of a semantic dependency relationship defined by the protocol, and the global timestamp difference being within the time-series association interval. The reorganization unit 704 is used to obtain the global timestamps of each associated transaction in each associated group recorded in the global transaction index structure, and reorganize the associated transactions in the group into a complete processing link according to the order of the global timestamps, so as to realize the time sequence restoration of out-of-order requests.

[0133] Optionally, the observation unit 701 is specifically used for: The original protocol data of each transaction entering the main node proxy is collected synchronously through the unified observation point. Parse the original protocol data to obtain key transaction information and transaction type for each transaction; According to the transaction type, the key transaction information is classified and archived into a request queue, response queue, sniffing queue, or data queue; wherein, the archived key transaction information is used to perform subsequent association group division steps.

[0134] Optionally, the global transaction index structure is implemented using a hash table, wherein: The key of the hash table is the global transaction identifier; The hash table's value is a structure containing the key transaction information and a list of associated pointers; the list of associated pointers is used to store pointers to entries of other transactions within the same association group in the global transaction index structure.

[0135] Optionally, the key transaction information also includes response codes and / or cache status, and the archiving unit 702 is specifically used for: The response code and / or cache status are mapped to preset standard status values, and the standard status values ​​are written into the global transaction index structure.

[0136] Optionally, the association unit 703 is specifically used for: Using the target address as the first matching key, filter out at least one first-level candidate transaction set with the same target address; In each first-level candidate transaction set, at least one second-level candidate transaction set with the same original transaction identifier is selected using the original transaction identifier as the second matching key. In each secondary candidate transaction set, at least one tertiary candidate transaction set is selected based on the opcode as the third matching key, either with the same opcode or with a semantic dependency defined by the protocol. In each third-level candidate transaction set, using the global timestamp as the fourth matching key, multiple transactions whose global timestamp differences are within the same time-series correlation interval are selected, and these multiple transactions are assigned to the same correlation group.

[0137] Optionally, the association unit 703 is specifically used for: The related transactions within the group are initially sorted according to the ascending order of the global timestamps. If multiple related transactions with the same global timestamp exist after the initial sorting, then these multiple related transactions are sorted in a secondary order according to the numerical value of the source port number.

[0138] Optionally, the width of the time-series correlation interval is a preset fixed value; or, The width of the time-series correlation interval is determined based on the microarchitecture parameters of the master node agent, which include at least one of the following: internal pipeline stage number, arbitration latency, sniffing response timeout threshold, downstream storage access latency, and maximum waiting period for flow control credit return.

[0139] Optionally, a log generation unit 705 is also included, for: Based on the complete processing chain, protocol anomaly events are detected; wherein, the protocol anomaly events include response loss, transaction timeout and / or deadlock; In response to the detection of any protocol anomaly event, the link node in the complete processing chain where the anomaly occurred is located, and a verification log for the link node is generated.

[0140] Optionally, the log generation unit 705 is specifically used for: Based on the anomaly type of any of the protocol anomaly events, determine error correction suggestion information matching the anomaly type, and generate a verification log containing the error correction suggestion information; The error correction suggestions include at least one of the following: suggested investigation of the master node agent internal sub-modules, sniffing filter state machine verification direction, storage subsystem path inspection direction, and flow control credit return mechanism inspection direction.

[0141] Optionally, a log filtering unit 706 is also included, for: Receive filtering instructions input by the user, the filtering instructions including transaction type, physical port number and / or transaction status; According to the filtering instructions, target log entries that conform to the filtering instructions are filtered from the full verification logs and output.

[0142] Accordingly, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the methods described in any of the above embodiments.

[0143] Accordingly, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method as described in any of the above embodiments.

[0144] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0145] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0146] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0147] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

Claims

1. An on-chip transaction verification method, characterized in that, A verification system applied to a system-on-a-chip (SoC) includes a master node agent that manages consistency transactions between multiple upstream request nodes and a downstream storage subsystem. The master node agent has a unified observation point set up at the port facing the multiple request nodes. The method includes: Through the unified observation point, transaction information of each transaction entering the master node agent is collected synchronously, wherein the key transaction information of each transaction includes at least the original transaction identifier, source port number, target address, opcode and global timestamp. Assign a global transaction identifier to each transaction, and use the global transaction identifier as an index to write the key transaction information of each transaction into the global transaction index structure; Based on the key transaction information, multiple transactions that meet the preset association conditions are divided into the same association group, and the association relationship between each associated transaction in each group is established in the global transaction index structure; wherein, the preset association conditions include: the same target address, the same original transaction identifier, the same opcode or the existence of a semantic dependency relationship defined by the protocol, and the global timestamp difference being within the time-series association interval; For each associated group recorded in the global transaction index structure, the global timestamps of each associated transaction in the group are obtained from the global transaction index structure, and the associated transactions in the group are reassembled into a complete processing chain according to the order of the global timestamps, so as to realize the time sequence restoration of out-of-order requests.

2. The method according to claim 1, characterized in that, The process of synchronously collecting transaction information of each transaction entering the master node proxy through the unified observation point includes: The original protocol data of each transaction entering the main node proxy is collected synchronously through the unified observation point. Parse the original protocol data to obtain key transaction information and transaction type for each transaction; According to the transaction type, the key transaction information is classified and archived into a request queue, response queue, sniffing queue, or data queue; wherein, the archived key transaction information is used to perform subsequent association group division steps.

3. The method according to claim 1, characterized in that, The global transaction index structure is implemented using a hash table, wherein: The key of the hash table is the global transaction identifier; The hash table's value is a structure containing the key transaction information and a list of associated pointers; the list of associated pointers is used to store pointers to entries of other transactions within the same association group in the global transaction index structure.

4. The method according to claim 1, characterized in that, The key transaction information also includes response codes and / or cache states. The step of writing the key transaction information of each transaction into the global transaction index structure includes: The response code and / or cache status are mapped to preset standard status values, and the standard status values ​​are written into the global transaction index structure.

5. The method according to claim 1, characterized in that, The step of grouping multiple transactions that meet preset association conditions into the same association group based on the key transaction information includes: Using the target address as the first matching key, filter out at least one first-level candidate transaction set with the same target address; In each first-level candidate transaction set, at least one second-level candidate transaction set with the same original transaction identifier is selected using the original transaction identifier as the second matching key. In each secondary candidate transaction set, at least one tertiary candidate transaction set is selected based on the opcode as the third matching key, either with the same opcode or with a semantic dependency defined by the protocol. In each third-level candidate transaction set, using the global timestamp as the fourth matching key, multiple transactions whose global timestamp differences are within the same time-series correlation interval are selected, and these multiple transactions are assigned to the same correlation group.

6. The method according to claim 1, characterized in that, The step of reorganizing the related transactions within the group into a complete processing chain according to the global timestamp sequence includes: The related transactions within the group are initially sorted according to the ascending order of the global timestamps. If multiple related transactions with the same global timestamp exist after the initial sorting, then these multiple related transactions are sorted in a secondary order according to the numerical value of the source port number.

7. The method according to claim 1, characterized in that, The width of the time-series correlation interval is a preset fixed value; or, The width of the time-series correlation interval is determined based on the microarchitecture parameters of the master node agent, which include at least one of the following: internal pipeline stage number, arbitration latency, sniffing response timeout threshold, downstream storage access latency, and maximum waiting period for flow control credit return.

8. The method according to any one of claims 1-7, characterized in that, Also includes: Based on the complete processing chain, protocol anomaly events are detected; wherein, the protocol anomaly events include response loss, transaction timeout and / or deadlock; In response to the detection of any protocol anomaly event, the link node in the complete processing chain where the anomaly occurred is located, and a verification log for the link node is generated.

9. The method according to claim 8, characterized in that, The generation of verification logs for the link node includes: Based on the anomaly type of any of the protocol anomaly events, determine error correction suggestion information matching the anomaly type, and generate a verification log containing the error correction suggestion information; The error correction suggestions include at least one of the following: suggested investigation of the master node agent internal sub-modules, sniffing filter state machine verification direction, storage subsystem path inspection direction, and flow control credit return mechanism inspection direction.

10. The method according to claim 8, characterized in that, Also includes: Receive filtering instructions input by the user, the filtering instructions including transaction type, physical port number and / or transaction status; According to the filtering instructions, target log entries that conform to the filtering instructions are filtered from the full verification logs and output.

11. A verification system, characterized in that, The on-chip system corresponding to the verification system includes a master node agent and multiple upstream request nodes and a downstream storage subsystem. The master node agent manages consistency transactions between the multiple request nodes and the storage subsystem. The master node agent sets up a unified observation point at the port facing the multiple request nodes. The verification system includes a global port capturer, a global transaction index module, and a multi-dimensional cross-transaction matching engine. The global port capture device is used to synchronously collect transaction information of each transaction entering the master node agent through the unified observation point. The key transaction information of each transaction includes at least the original transaction identifier, source port number, target address, opcode and global timestamp. The global transaction index module is used to assign a global transaction identifier to each transaction and write the key transaction information of each transaction into the global transaction index structure using the global transaction identifier as an index. The multi-dimensional cross-transaction matching engine is used to divide multiple transactions that meet preset association conditions into the same association group according to the key transaction information, and to establish the association relationship between each associated transaction in each group in the global transaction index structure; wherein, the preset association conditions include: the same target address, the same original transaction identifier, the same opcode or the existence of a semantic dependency relationship defined by the protocol, and the global timestamp difference being within the time-series association interval. The transaction flow reassembler is used to obtain the global timestamps of each associated transaction in each associated group recorded in the global transaction index structure, and reassemble the associated transactions in the group into a complete processing link according to the order of the global timestamps, so as to realize the time sequence restoration of out-of-order requests.

12. The system according to claim 11, characterized in that, The verification system is implemented based on the universal verification methodology UVM platform, wherein, The global port capturer, the global transaction index module, the multidimensional cross-transaction matching engine, and the transaction flow reassembler are each implemented by independent UVM components and are dynamically configured to be enabled or disabled through the UVM configuration database.

13. The system according to claim 11, characterized in that, The verification system is deployed within the master node agent; or... The verification system is independent of the master node agent.

14. An on-chip transaction verification device, characterized in that, A verification system applied to a system-on-a-chip (SoC) includes a master node agent that manages consistency transactions between multiple upstream request nodes and a downstream storage subsystem. The master node agent has a unified observation point set up at the port facing the multiple request nodes. The device includes: The observation unit is used to synchronously collect transaction information of each transaction entering the master node agent through the unified observation point, wherein the key transaction information of each transaction includes at least the original transaction identifier, source port number, target address, opcode and global timestamp. The archive unit is used to assign a global transaction identifier to each transaction and write the key transaction information of each transaction into the global transaction index structure using the global transaction identifier as an index. The association unit is used to divide multiple transactions that meet preset association conditions into the same association group according to the key transaction information, and to establish the association relationship between each associated transaction in each group in the global transaction index structure; wherein, the preset association conditions include: the same target address, the same original transaction identifier, the same opcode or the existence of a semantic dependency relationship defined by the protocol, and the global timestamp difference being within the time-series association interval; The reorganization unit is used to obtain the global timestamps of each associated transaction in each associated group recorded in the global transaction index structure, and reorganize the associated transactions in the group into a complete processing link according to the order of the global timestamps, so as to realize the time sequence restoration of out-of-order requests.

15. An electronic device, characterized in that, It includes a processor and a memory for storing processor-executable instructions; wherein the processor implements the method as described in any one of claims 1-10 by executing the executable instructions.

16. A machine-readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1-10.

Images