A method and system for data path verification of an SOC
By building adaptive port monitors and system monitors in the SoC, combined with predictors and comparators, full-link monitoring and consistency checks of the data path are achieved, solving the problems of insufficient coverage, low efficiency and difficulty in localization in SoC verification, and improving the accuracy and efficiency of verification.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 奕行智能科技(广州)有限公司
- Filing Date
- 2026-04-29
- Publication Date
- 2026-05-29
AI Technical Summary
Existing technologies struggle to achieve comprehensive coverage in complex SoC multi-protocol conversion scenarios, resulting in low verification efficiency, timing compatibility issues, and significant debugging and localization difficulties, leading to insufficient verification coverage, low efficiency, and localization delays.
By constructing adaptive port monitors and system monitors, the system enables end-to-end monitoring, protocol conversion, and consistency checks of the data path. It also generates error reports using predictors and comparators, supporting multi-protocol conversion verification.
It improves the coverage and efficiency of SoC verification, shortens error location time, adapts to the diversity and dynamism of complex bus structures, and enhances the accuracy and efficiency of verification.
Smart Images
Figure CN122113835A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of digital integrated circuit design and verification technology, and in particular to a data path verification method and system for a System-on-a-Chip (SOC). Background Technology
[0002] With semiconductor processes entering the nanometer scale and the continuous improvement of integrated circuit design, the integration and functional complexity of System-on-Chips (SoCs) are growing exponentially, making them a core component of high-end electronic devices such as smartphones, autonomous driving, and artificial intelligence. SoC chips achieve a high degree of integration of complex system functions by integrating functional modules such as processor cores, memory controllers, peripheral interfaces, and signal processing units onto a single silicon chip. Among these, the data path, as the core carrier for data interaction and message transmission between SoC modules, directly determines the overall performance of the chip. Depending on the SoC architecture design requirements, the data path typically consists of one or more bus systems. Commonly used bus protocols in modern SoCs include AXI, AHB, APB, and CHI from the AMBA series. These bus protocols form a complex network of interconnected pathways, undertaking high-bandwidth data transmission and control signal interaction between modules.
[0003] In the SoC design flow, verification accounts for 50% to 80% of the workload and is a critical step in ensuring successful chip tape-out. Verifying the correctness of the data path is the core of SoC verification, aiming to ensure that data transmission between modules conforms to protocol specifications and that there is no data loss or incorrect routing. Current mainstream verification solutions employ a combination of simulation and formal verification, conducting functional verification through methods such as building verification environments, generating test stimuli, and writing assertions. However, as SoC scale continues to increase, bus architectures exhibit complex characteristics such as multi-master / multi-slave, multi-protocol hybrid, and cross-clock domain interconnects. Existing verification methods face significant challenges, primarily in the following four aspects: Insufficient verification coverage: The data paths of complex SoCs contain massive combinations of transmission paths and states. Traditional random stimulus generation methods struggle to cover all address conflict scenarios, burst transmission modes, and abnormal response handling paths, resulting in some potential design flaws (bugs) going undetected before tape-out. For example, Chinese patent CN120949010A discloses a routing path verification method based on address translation model functions, which verifies routing correctness by comparing generated standard addresses with actual addresses. However, this method is only applicable to single-protocol scenarios. In multi-protocol conversion processes such as AXI and APB, the lack of deep analysis capabilities for transaction attributes and data formats prevents coverage of path anomaly scenarios caused by protocol conversion.
[0004] Low verification efficiency: Modern bus protocols (such as AXI4) contain hundreds of rules, involving multiple dimensions such as transaction type, timing constraints, and data integrity. For complex bus architectures, a massive amount of test code and assertion statements need to be written, resulting in long setup cycles and high maintenance costs for verification environments. Chinese patent CN117056151B discloses a path verification method with an embedded bus verification module, which achieves connection verification by sampling master-slave device port signals and modeling bus mapping relationships. However, this solution does not support dynamic data format conversion in multi-protocol mixed scenarios and lacks an effective verification mechanism for complex interaction scenarios such as burst transmission splitting and address alignment conversion from AXI to APB, thus limiting verification efficiency and scenario adaptability.
[0005] Timing and protocol compatibility issues: In heterogeneous bus interconnection scenarios, different protocols exhibit significant differences in timing characteristics and transaction formats (e.g., AXI supports out-of-order transmission and variable burst length, while APB only supports single-cycle synchronous transmission). During protocol conversion, issues such as timing mismatches, protocol violations, or data loss can easily occur. Existing verification monitors are mostly designed for single protocols and lack deep semantic analysis capabilities for multi-protocol conversion. They cannot simultaneously verify key aspects of the conversion process, such as address mapping, data width adaptation, and handshake mechanism compatibility, making it difficult to cover compliance issues arising from protocol conversion.
[0006] Debugging and troubleshooting are challenging: Complex SoCs have data paths characterized by deep hierarchy, high signal density, and high transaction concurrency. When errors are discovered during verification, existing tools struggle to trace the complete data transmission chain and quickly pinpoint the root cause—whether it's an anomaly in the source module's transmission, an intermediate routing error, or a failure in the destination module's reception. This delay in troubleshooting extends the design iteration cycle, significantly increasing chip development costs and tape-out risks.
[0007] The essence of the aforementioned problems lies in the fact that existing verification methods fail to adequately adapt to the protocol diversity, timing differences, and path dynamics of complex bus architectures, lack deep coverage of multi-protocol conversion scenarios, and have not established an efficient error tracing mechanism. Although existing technologies have proposed some targeted solutions (such as the address comparison method in CN120949010A and the bus mapping modeling method in CN117056151B), they all have limitations in scenario adaptability and cannot comprehensively solve the coverage, efficiency, and debugging problems in large-scale SoC verification. Therefore, there is an urgent need for a data path correctness verification method that can adapt to complex bus structures, support multi-protocol conversion verification, and balance coverage integrity and verification efficiency to meet the design verification needs of modern SoCs. Summary of the Invention
[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide a SOC data path verification method. By constructing an adaptive port monitor and system monitor, the method realizes full-link monitoring, protocol conversion and consistency check of the data path, thereby improving verification efficiency and accuracy.
[0009] This invention provides a data path verification method for a System-on-a-Chip (SOC), wherein the SOC includes multiple functional modules and data paths connecting the functional modules, and the method includes: The system monitor manages the cache of read and write operations in the data path based on the configuration information, and the predictor generates the expected data path behavior results based on the cached read and write operations. The comparator compares the actual data path transmission results with the expected data path behavior results generated by the predictor. If the comparison results are inconsistent, an error report will be generated and the abnormal waveform will be recorded.
[0010] In one embodiment of the present invention, it further includes: Initialize the verification environment and load the SOC netlist and verification platform model; Port monitors are deployed at the corresponding ports of the data path. The port monitors are used to capture bus signals on the ports and perform protocol checks and data format conversions according to preset bus protocols to generate unified format data. The unified format data is sent to the system monitor to complete the cache management of read and write operations in the data path.
[0011] In one embodiment of the present invention, the protocol check and data format conversion according to the preset bus protocol includes: The data acquisition unit samples the control signals, address signals, data signals, and error signals of the bus at clock cycles. The protocol inspection unit parses the sampled signals according to the bus protocol standard and combines them into a complete transaction description. The parsed transaction is converted into an internally unified format data structure that is independent of the protocol through the data transmission unit.
[0012] In one embodiment of the present invention, the system monitor performs cache management on read and write operations in the data path based on configuration information, including: Write operation information is stored in the write cache, and the write cache is checked for dirty data when a subsequent read request occurs. The information of read operations is stored in the read cache, and the return order of read responses is tracked to perform sequence matching of out-of-order responses.
[0013] In one embodiment of the present invention, generating an error report and recording abnormal waveforms includes: Record the transaction ID, occurrence time, expected value, and measured value of the error; Record several transaction history entries prior to the error, and provide a related waveform screenshot index; The verification process pauses and enters interactive mode when preset conditions are met.
[0014] In one embodiment of the present invention, the step of generating the expected data path behavior result through the predictor includes: Simulate the data routing logic and arbitrator priority logic inside the SOC to determine the expected response order when multiple master devices contend for the bus. Based on the received request signals, predict the expected response data and latency.
[0015] The present invention also provides a data path verification system for a System-on-Chip (SOC), the system comprising: The initialization module is used to load the netlist of the SOC design and the verification platform model. Functional modules include: The main module is configured to actively send transmission requests; The module is configured to passively receive transmission requests; The port monitoring module is deployed at key ports of the data path of each functional module to capture bus signals and perform protocol checks and data format conversions. The system monitoring module is used to receive data in a unified format, perform read and write operation cache management, and predict behavior.
[0016] In one embodiment of the present invention, the port monitoring module includes: The configuration information unit is configured to configure the operating mode of the port monitor; A data acquisition unit, configured to acquire information from the monitored ports; The protocol checking unit is configured to perform protocol checks on port operations based on configuration information, covering both standard and proprietary protocols; Data transmission is configured to convert and package the collected data according to the configuration information and then transmit it to the system monitor.
[0017] In one embodiment of the present invention, the system monitoring module includes: Configuration information, which is configured to configure the operating mode of the system monitor; Write cache, which is configured to store information about write operations; Read cache, which is configured to store information about read operations; The predictor is configured to predict routing information based on the request information passed from the main module. The comparator is configured to check the correctness of the data path based on the results of the predictor.
[0018] In one embodiment of the present invention, an attribute adaptation module is further included, which is configured to directly read the internal status register of the read-only or write-only module to verify the correctness of the data path update.
[0019] The present invention has the following beneficial effects: (1) By combining the port monitor and the system monitor, full coverage monitoring of the data path from the physical layer to the protocol layer is achieved, which effectively solves the problem of insufficient verification coverage under complex bus structure.
[0020] (2) The port monitor supports the format conversion of multiple bus protocols, which enables the system monitor to process based on a unified format, reducing the difficulty of adapting to heterogeneous bus architectures.
[0021] (3) The system monitor has built-in prediction and comparison functions, which can accurately locate the path nodes where the error occurs and generate an error report containing detailed waveform information, thus shortening the problem location time.
[0022] (4) It can dynamically adjust the verification strategy according to the access attributes of the data path (such as read-only or write-only) to adapt to the architectural characteristics of different SOC chips. Attached Figure Description
[0023] Figure 1 A flowchart illustrating a SOC data path verification method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the architecture of a SOC data path verification system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the internal logic structure of a port monitor provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the internal functional modules of a system monitor provided in an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the correctness check of system monitor data provided in an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating the system monitor routing correctness check provided in an embodiment of the present invention. Detailed Implementation
[0024] In the following description, the invention is described with reference to various embodiments. However, those skilled in the art will recognize that the embodiments may be practiced without one or more specific details or with other alternatives and / or additional methods, materials, or components. In other instances, well-known structures, materials, or operations are not shown or described in detail so as not to obscure the inventive points of the invention. Similarly, for illustrative purposes, specific quantities, materials, and configurations are set forth to provide a comprehensive understanding of embodiments of the invention. However, the invention is not limited to these specific details.
[0025] In this invention, the various embodiments are merely intended to illustrate the solutions of the invention and should not be construed as limiting.
[0026] In this specification, references to "an embodiment" or "this embodiment" mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the invention. The phrase "in one embodiment" appearing throughout this specification does not necessarily refer to the same embodiment in all instances.
[0027] Furthermore, the numbering of the steps in the methods of the present invention does not limit the execution order of the method steps. Unless otherwise specified, the method steps may be executed in different orders.
[0028] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.
[0029] Figure 1 This is a flowchart illustrating a SOC data path verification method provided in an embodiment of the present invention.
[0030] like Figure 1 As shown, in this embodiment, the SOC data path verification method includes: S1. Initialize the verification environment. The verification environment is built based on the Unified Verification Methodology (UVM) or a similar framework. In this step, the gate-level netlist or register-transfer-level (RTL) code of the SOC design to be verified is loaded. At the same time, the component models in the verification platform are instantiated, including the design under test (DUT), the scoreboard driver, the monitor, etc.
[0031] S2. Deploy Port Monitors. Deploy port monitors at key nodes in the data path. These key nodes include the master and slave module interfaces. The port monitors capture bus control signals (such as Valid, Ready), address signals, data signals, and error signals in real time. The core function of the port monitor is protocol checking and format conversion. For example, when the DUT uses the AXI4 protocol, the port monitor checks whether the write burst sequence is correct and whether the addresses are aligned. Subsequently, the captured raw signal sequence is converted into a unified internal data structure, such as a structure containing transaction ID, starting address, data payload, and operation type (Read / Write).
[0032] S3. Data is transmitted to the system monitor. The converted transaction data is transmitted to the system monitor via the verification bus. The system monitor, as the core logic unit for verification, is responsible for maintaining the global data path status.
[0033] S4. System Monitor Processing and Prediction. The system monitor internally includes a configuration module, read / write cache, predictor, and comparator. The configuration module is used to set verification scenarios, such as defining which address ranges are valid and which transmission modes need to be checked. The read / write cache records recently occurring transactions for matching in out-of-order transmission scenarios. The predictor predicts the expected response based on received request signals and the DUT's architectural logic. For example, for write transactions, the predictor records the address and data; for read transactions, the predictor simulates latency and data return from the slave device.
[0034] S5. Result Comparison and Error Reporting. The comparator receives the actual transmitted data from the port monitor and the expected data from the predictor. The comparison logic includes address comparison, data comparison, and error flag comparison. If the two are inconsistent, the comparator triggers an error interrupt, and the verification platform generates an error report (Error Log). This report includes the transaction ID, occurrence time, expected and measured values, and related waveform screenshot indexes.
[0035] S6. Access Attribute Adaptation. For special read-only memory (ROM) or write-only registers (WatchdogTimer) in the SOC, the port monitor directly reads the module's internal status registers via a "backdoor" method to verify whether the data path has correctly updated these states, rather than simply checking the bus signals.
[0036] Figure 2 This is a schematic diagram of the architecture of a SOC data path verification system provided in an embodiment of the present invention.
[0037] A System-on-a-Chip (SoC) typically contains multiple master and slave modules; some modules can function as both master and slave. The bus structure in an SoC also varies, including ring buses, star buses, mesh buses, and so on. For ease of explanation, Figure 2 The proposed system has been simplified. In principle, since the proposed data path verification system only relies on port monitors and system monitors for bus behavior checks, it is compatible with any form of bus structure and any number of master / slave modules, as well as complex data path structures composed of multiple bus systems.
[0038] When the SOC system is operating, the port monitor collects necessary information and transmits it to the system monitor. This collection is unidirectional, capturing data from the interface, and therefore does not affect the operation of the modules or the bus. The collected information is transmitted to the system monitor through the verification environment's transmission mechanism. The system monitor checks the bus's operating status, especially the correctness of data and routing, and reports any errors that occur.
[0039] Since port monitors and system monitors exist as simulation components in the verification environment, these checks targeting the data path will apply to all simulation use cases, not just dedicated data path verification use cases.
[0040] In this embodiment, as Figure 2 As shown, there are two main modules in the system: main module 11 and main module 12.
[0041] The system has three slave modules: slave module 21, slave module 22, and slave module 23. (They will be referred to as slave 1, slave 2, and slave 3 in the following diagram.) The number of write caches 42 in system monitor 40 is equal to the number of slave modules. In this example, there are three write caches 42 and three read caches 43.
[0042] The number of predictors 44 in the system monitor 40 is equal to the number of main modules; in this example, there are two predictors 44.
[0043] In this embodiment, the system includes: Main module 10: The module that actively sends transmission requests.
[0044] From module: A module that passively receives transmission requests.
[0045] Port Monitor 30: Monitors the interface between the module and the bus, and collects the necessary data to transmit to the system monitor.
[0046] System Monitor 40: Checks the correctness of data paths based on information and configuration information from port monitors.
[0047] Bus 50: The structure that connects the master module and the slave module.
[0048] Among them, such as Figure 3 As shown, the port monitor 30 includes: Configuration information unit 31: Configures the operating mode of port monitor 30.
[0049] Data acquisition unit 32: Collects information about the monitored ports.
[0050] Protocol inspection unit 33: Based on configuration information, it performs protocol inspection on port operations, which can cover both standard protocols and proprietary protocols.
[0051] Data transmission unit 34: Based on the configuration information, it converts and packages the collected data and transmits it to the system monitor 40.
[0052] Port monitors are used to monitor the information exchange between various modules and the bus system in the data path. Only ports that require data path monitoring need to have port monitors implemented. These monitors can operate in different modes based on different port attributes, such as protocol type and address characteristics.
[0053] Port monitors are adapted to the monitored ports. While performing protocol checks on the ports, they often convert various types of protocol data into a unified internal data processing format as needed, making it easier for subsequent system monitors to process.
[0054] In addition, depending on the different data path access attributes, such as read-only or write-only, some port monitors need to use a "backdoor" method to obtain information from the slave module, which will not be elaborated here.
[0055] like Figure 4 As shown, in this embodiment, the system monitor 40 includes: Configuration information 41: Configure the operating mode of system monitor 40.
[0056] Write cache 42: Used to store information about write operations.
[0057] Read cache 43: Used to store information about read operations.
[0058] Predictor 44: Predicts routing information based on the request information passed from the main module.
[0059] Comparator 45: Checks the correctness of the data path based on the predictor's results.
[0060] System monitors are relatively complex to implement, especially the predictors and comparators. They need to perform a comprehensive check of the data path based on information from numerous port monitors and configuration information. In some cases, they also need to handle address conflicts and out-of-order data.
[0061] A comprehensive data pathway inspection includes the following three aspects: Protocol check: Checks if the data transmission conforms to the configured protocol type.
[0062] Data correctness check: Perform correctness checks on write and read data at the same address.
[0063] Route correctness check: Check that each data request is correctly routed to its corresponding destination.
[0064] Protocol checks are performed by the port monitor. Protocol checks are specific to certain protocol types and will not be discussed further here.
[0065] Data correctness checks and routing correctness checks are performed by the system monitor.
[0066] It is important to note that specific system monitors have various implementation structures depending on the chip architecture and data path characteristics. For example, whether to separate read and write caches, whether the number of caches corresponds to the master module or the slave module, and whether the number of predictors corresponds to the master module or the slave module, etc.
[0067] Figure 5 This is a schematic diagram illustrating the correctness check of system monitor data provided in an embodiment of the present invention.
[0068] like Figure 5 As shown, this example illustrates the write and read operation flow initiated by the main module 11.
[0069] The master module 11 sends a write operation to each of the slave modules 21 (from 1), 22 (from 2), and 23 (from 3).
[0070] The master module 11 sends a read operation to each of the slave modules 21, 22, and 23 respectively.
[0071] The main modules 11 and 12 each sent a write operation and a read operation to the slave module 21.
[0072] For simplicity, the diagram above omits the predictor of main module 12, the read / write cache of slave module 22, and the read / write cache of slave module 23.
[0073] When the predictor of master module 11 receives write operation 1, it predicts, based on the configuration information, that this operation should be sent to slave module 21, marks the operation, and then sends it to the comparator. When the predictor of master module 11 receives read operation 1, it predicts, based on the configuration information, that this operation should be sent to slave module 21, marks the operation, and then sends it to the comparator. The comparator compares the received read operation information with all write operations marked with slave module 21. If a matching information is found, the comparison is considered successful, and the corresponding write operation is removed from the comparator. If no matching information is found, the comparison is considered unsuccessful, and an error is reported to the verification environment.
[0074] In the example, all components work in parallel, and the platform eventually collects all the information to determine whether the bus is working correctly.
[0075] Figure 6 This is a schematic diagram illustrating the system monitor routing correctness check provided in an embodiment of the present invention.
[0076] like Figure 6 As shown, this example illustrates the check process for a write operation. The read operation process is similar.
[0077] The main module 11 sends one, two, and three write operations to the slave modules 21 (from 1), 22 (from 2), and 23 (from 3), respectively.
[0078] The main module 12 sends two-stroke, two-stroke, and three-stroke write operations to the slave modules 21, 22, and 23, respectively.
[0079] The operations of main module 11 and main module 12 are performed completely independently.
[0080] For the sake of simplicity, the main module 11 read cache, slave module 22 read cache, and slave module 23 read cache are omitted from the diagram above.
[0081] Three write operations were received from the port monitor of module 21 and passed to the corresponding write buffer in the system monitor. Correspondingly, four and six write operations were received from the port monitors of module 22 and module 23, respectively, and stored in the write buffer of the system monitor.
[0082] When the predictor in master module 11 receives write operation 1, it predicts, based on the configuration information, that this operation should be sent to slave module 21. After marking the operation, it sends it to the comparator. The comparator compares the received write operation with existing write operations in the write cache of slave module 21. If a match is found, the comparison is considered successful, and the write operation is removed from the write cache. If no match is found, the comparison is considered unsuccessful, and an error is reported to the verification environment.
[0083] In the example, all components work in parallel, and the platform eventually collects all the information to determine whether the bus is working correctly.
[0084] In practice, the protocol correctness check, data correctness check, and routing correctness check in the above example are all performed simultaneously. Based on the information received by the port monitor, the entire data path is comprehensively and instantly verified.
[0085] Although various embodiments of the invention have been described above, it should be understood that they are presented by way of example only and not as limitations. It will be apparent to those skilled in the art that various combinations, modifications, and alterations can be made without departing from the spirit and scope of the invention. Therefore, the breadth and scope of the invention disclosed herein should not be limited by the exemplary embodiments disclosed above, but should be defined solely by the appended claims and their equivalents.
Claims
1. A data path verification method for a System-on-a-Chip (SOC), wherein the SOC includes multiple functional modules and data paths connecting the functional modules, characterized in that, The method includes: The system monitor manages the cache of read and write operations in the data path based on the configuration information, and the predictor generates the expected data path behavior results based on the cached read and write operations. The comparator compares the actual data path transmission results with the expected data path behavior results generated by the predictor. If the comparison results are inconsistent, an error report will be generated and the abnormal waveform will be recorded.
2. The method according to claim 1, characterized in that, Also includes: Initialize the verification environment and load the SOC netlist and verification platform model; Port monitors are deployed at the corresponding ports of the data path. The port monitors are used to capture bus signals on the ports and perform protocol checks and data format conversions according to preset bus protocols to generate uniform format data. The unified format data is sent to the system monitor to complete the cache management of read and write operations in the data path.
3. The method according to claim 2, characterized in that, The protocol check and data format conversion according to the preset bus protocol includes: The data acquisition unit samples the control signals, address signals, data signals, and error signals of the bus at clock cycles. The protocol inspection unit parses the sampled signals according to the bus protocol standard and combines them into a complete transaction description. The parsed transaction is converted into an internally unified format data structure that is independent of the protocol through the data transmission unit.
4. The method according to claim 1, characterized in that, The system monitor performs cache management on read and write operations in the data path based on configuration information, including: Write operation information is stored in the write cache, and the write cache is checked for dirty data when a subsequent read request occurs. The information of read operations is stored in the read cache, and the return order of read responses is tracked to perform sequence matching of out-of-order responses.
5. The method according to claim 1, characterized in that, The generation of error reports and recording of abnormal waveforms includes: Record the transaction ID, occurrence time, expected value, and measured value of the error; Record several transaction history entries prior to the error, and provide a related waveform screenshot index; The verification process pauses and enters interactive mode when preset conditions are met.
6. The method according to claim 1, characterized in that, The generation of expected data path behavior results through the predictor includes: Simulate the data routing logic and arbitrator priority logic inside the SOC to determine the expected response order when multiple master devices contend for the bus. Based on the received request signals, predict the expected response data and latency.
7. A data path verification system for a System-on-a-Chip (SOC), characterized in that, The system includes: The initialization module is used to load the netlist of the SOC design and the verification platform model. Functional modules include: The main module is configured to actively send transmission requests; The module is configured to passively receive transmission requests; The port monitoring module is deployed at key ports of the data path of each functional module to capture bus signals and perform protocol checks and data format conversions. The system monitoring module is used to receive data in a unified format, perform read and write operation cache management, and predict behavior.
8. The SOC data path verification system according to claim 7, characterized in that, The port monitoring module includes: The configuration information unit is configured to configure the operating mode of the port monitor; A data acquisition unit, configured to acquire information from the monitored ports; The protocol checking unit is configured to perform protocol checks on port operations based on configuration information, covering both standard and proprietary protocols; Data transmission is configured to convert and package the collected data according to the configuration information and then transmit it to the system monitor.
9. The SOC data path verification system according to claim 7, characterized in that, The system monitoring module includes: Configuration information, which is configured to configure the operating mode of the system monitor; Write cache, which is configured to store information about write operations; Read cache, which is configured to store information about read operations; The predictor is configured to predict routing information based on the request information passed from the main module. The comparator is configured to check the correctness of the data path based on the results of the predictor.
10. The SOC data path verification system according to claim 7, characterized in that, It also includes an attribute adaptation module, which is configured to directly read the internal status registers of read-only or write-only modules to verify the correctness of data path updates.