A uvm-based on-chip network switch verification method and platform

Abstract

This invention provides a UVM-based on-chip network switch verification method and platform, belonging to the field of chip verification technology. This invention synchronously sends the transaction to be tested to the DUT and a reference model, ensuring that both are processed in parallel based on the same stimulus, guaranteeing the accuracy of the verification comparison. Simultaneously, before processing the transaction, the reference model obtains the latest routing table from the DUT and synchronizes it to the routing table mirroring module, achieving real-time consistency of the routing tables between the two, completely avoiding false alarms caused by inconsistent routing configurations, and significantly improving the reliability of the verification results. Furthermore, the reference model performs concurrent processing of the entire process of transaction execution—receiving, routing decision-making, descriptor pairing, and data forwarding—utilizing the multi-threading capabilities of the simulator to shorten the simulation time for transaction processing, solving the problem of low efficiency in traditional verification methods, and achieving dual optimization of verification accuracy and efficiency.

Description

Technical Field

[0001] This invention relates to the field of chip verification technology, and in particular to a UVM-based on-chip network switch verification method and platform. Background Technology

[0002] With the rapid iteration of technologies such as artificial intelligence and high-performance computing, the bandwidth, latency, and concurrency requirements of modern systems on chips (SoCs) are continuously increasing. Network on chip (NoC), as the core interconnect architecture within the chip, undertakes the task of data routing and forwarding between computing units. As a key component of NoC, the functional complexity of network on chip switches is growing exponentially. These switches need to support multiple routing modes, such as multi-channel parallel transmission, switch-to-switch (S2S), switch-to-memory node (S2MN), and switch-to-quadrant node manager (S2QNM) routing, as well as direct memory access (DMA) transaction transmission with message, command, data, and response separation. They also need to implement special functions such as 1-to-4 descriptor distribution, which makes the verification difficulty of switches far exceed that of traditional chip components.

[0003] Traditional verification methods generally employ a single large-task serial processing architecture, coupling all processing logic of descriptor channels, command channels, data channels, response channels, and message channels into a single task. Thus, when transactions arrive simultaneously from multiple channels, the hardware of the chip under test can process them concurrently within one clock cycle, while the verification end responsible for the verification process must execute each channel sequentially. This results in verification efficiency being only 1 / 5 or even lower than the hardware processing efficiency; a simple DMA transaction transfer simulation may take several hours. Furthermore, current verification processes often employ periodic precise modeling methods, requiring detailed simulation of handshake signals, flow control mechanisms, and arbitration logic for each clock cycle. This not only leads to high modeling complexity and a large amount of code, but also significantly increases simulation computational overhead, slowing down verification speed and further reducing verification efficiency. Summary of the Invention

[0004] This invention provides a UVM-based on-chip network switch verification method and platform, which solves the problem of low efficiency in the current on-chip network verification process and improves verification efficiency while ensuring verification accuracy.

[0005] In a first aspect, the present invention provides a UVM-based verification method for on-chip network switches, applied to the general verification methodology UVM verification platform. The method includes: generating a test transaction during the verification process and sending it to the Design Under Test (DUT) of the on-chip network switch and a reference model of the UVM verification platform; controlling the reference model to obtain the latest routing table in the DUT before processing the test transaction and synchronizing it to the routing table mirroring module built into the reference model, so that the routing table of the reference model and the DUT remains consistent; controlling the reference model to perform concurrent processing of the test transaction based on the latest routing table, including receiving, routing decision based on the routing table mirroring, descriptor pairing, and data forwarding, and outputting verification results; receiving and comparing the verification results of the reference model with the actual output results of the DUT to obtain a comparison verification result, thereby realizing the verification of the test transaction.

[0006] Secondly, embodiments of the present invention provide an on-chip network switch verification platform based on UVM. The verification platform includes a Control Status Register (CSR) configuration agent component, an agent component, a monitor, a coverage collector, a reference model, and a scoreboard. The reference model has a built-in routing table mirroring module. The verification platform stores a computer program, and the verification platform calls and runs the computer program to perform the method described in the first aspect above.

[0007] Thirdly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, characterized in that, when the computer program is executed by a processor, it implements the steps of the method as described in the first aspect and any possible implementation thereof.

[0008] This invention provides a UVM-based on-chip network switch verification method and platform. The invention synchronously sends the transaction to be tested to both the DUT and the reference model, ensuring that both are processed in parallel under the same stimulus, thus guaranteeing the accuracy of the verification comparison. Simultaneously, before processing the transaction, the reference model obtains the latest routing table from the DUT and synchronizes it to the routing table mirroring module, achieving real-time consistency between the two routing tables. This completely avoids false alarms caused by inconsistent routing configurations, significantly improving the reliability of the verification results. Furthermore, the reference model performs concurrent processing of the entire process of transaction execution—receiving, routing decision-making, descriptor pairing, and data forwarding—utilizing the simulator's multi-threading capabilities to shorten the simulation time for transaction processing, solving the inefficiency problem of traditional verification methods, and achieving a dual optimization of verification accuracy and efficiency. Attached Figure Description

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

[0010] Figure 1 This is a schematic diagram of the connection structure of a design under test (DUT) for an on-chip network switch provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of an on-chip network switch verification platform based on UVM provided in an embodiment of the present invention; Figure 3 This is a flowchart illustrating a UVM-based on-chip network switch verification method provided in an embodiment of the present invention. Figure 4 This is a schematic diagram of an on-chip network switch verification process provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the workflow of a reference model provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the workflow of a scoreboard provided in an embodiment of the present invention. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of the present invention clearer, the following description will be provided in conjunction with the accompanying drawings and specific embodiments.

[0012] As described in the background section, on-chip networks are a key component of modern high-performance chips, possessing crucial characteristics such as multi-channel parallel communication, multi-mode routing strategies, multi-chip interconnection, dynamic routing configuration, and complex DMA operations. These characteristics make on-chip networks one of the most complex and critical parts of chip verification. On-chip network verification is highly complex, has a significant impact from bugs (routing errors, deadlocks, packet loss, etc.), and incurs high verification costs.

[0013] Currently, there are several implementation methods for designing on-chip network verification reference models: (1) Traditional method based on a single routing table: using a unified routing table to handle all channel types and routing modes. This is the most common implementation method. The advantage is that it is simple to implement, but the disadvantage is that the routing decision accuracy is only 70-80%, and it cannot distinguish the differences between different channels and routing modes; (2) Method based on multiple routing tables but static configuration: establishing independent routing tables for each channel and routing mode, improving the routing decision accuracy to 85-90%. However, the routing table is configured once during initialization and is not updated afterward. It is impossible to track the dynamic modification of the routing table during runtime. When the hardware controls the status register (control and status register), the system will not update the routing table. (3) High-precision method based on periodic accurate modeling: detailed simulation of the behavior of hardware in each clock cycle, with an accuracy of 95-98% and a false alarm rate of 10-15%, but the development complexity is extremely high, the code volume is large, the development time is long, the simulation speed is extremely slow, and a simple DMA operation may take several hours to run; (4) Transaction-level modeling method based on System C language SystemC and transaction-level modeling (TLM) (register transfer layer): transaction-level abstraction improves development efficiency and simulation speed is fast, but integration with UVM environment is difficult, and it requires interaction through direct programming interface (DPI) interface, which has performance overhead, the debugging tools are immature, and the learning curve is steep; (5) High-level modeling method based on Python / C++: high development efficiency and concise code, but DPI interface overhead is large, data transmission is complex, environment configuration is complex, and there are still architectural problems of static routing table configuration and single processing task. The common drawbacks of these methods are: (a) Static configuration is a fundamental flaw. All methods configure the routing table during initialization and then do not update it, making it impossible to track dynamic routes. This is the root cause of the high false alarm rate; (b) Single processing task limits concurrency. Most methods use a single processing task to couple the processing logic of all channels together, which can only be executed serially and cannot take advantage of the simulator's concurrency capabilities; (c) The contradiction between accuracy and efficiency. Periodic precision modeling has high accuracy but extremely slow simulation speed, while transaction-level modeling has fast simulation speed but low accuracy. It is difficult to achieve both high accuracy and high efficiency at the same time.

[0014] Current on-chip network switch verification methods have serious defects in terms of accuracy, efficiency, maintainability, and coverage. In terms of accuracy: (1) Inaccurate routing table modeling, the single routing table method cannot distinguish between different channels and routing modes; (2) Unable to track dynamic routes, the traditional method does not update the routing table after initialization; (3) Lack of modeling for special scenarios, the traditional method lacks accurate modeling for special scenarios such as 1-to-4 descriptor distribution (one descriptor input and four descriptors output to four quadrant node manager (QNM) nodes) and broadcast mode, resulting in a large number of false alarms due to mismatch in quantity and content. In terms of efficiency: (1) Unable to process concurrently, the serial processing of the traditional method means that when transactions arrive at five channels at the same time, the hardware concurrent processing is completed in one cycle, while the reference model serial processing requires five cycles, which is five times slower; (2) High overhead for accurate cycle modeling, a direct memory access (DMA) operation to transfer 1024 bytes requires simulating about 1078 cycles. Maintainability defects: (1) High code coupling. Modifying the routing logic of the descriptor channel requires modifying the main processing task, which may affect other channels. All channels need to be retested, resulting in high risk and cost. (2) Lack of modular design. All logic is mixed in one large task. There is a lack of clear interface definition, making it difficult to develop and test independently and reuse in other projects. (3) Poor scalability. Adding a new communication channel requires modifying the main processing task, routing table structure, routing decision logic, scoreboard, coverage collection, etc., resulting in a large workload, long cycle, and high risk. Coverage defects: (1) Insufficient coverage of dynamic routing scenarios. Traditional methods configure the routing table during initialization and then do not update it. It is impossible to verify the correctness of dynamic modification of the routing table. The coverage rate of dynamic routing scenarios is 0%. (2) Insufficient coverage of multi-chip interconnection scenarios. Traditional methods only have one routing table and cannot distinguish between uplink and downlink. It is impossible to verify the independent routing of bidirectional traffic. The coverage rate of multi-chip interconnection scenarios is only 0-30%. (3) Insufficient coverage of complex DMA scenarios. Traditional methods lack descriptor pairing mechanism and DMA transaction-level modeling. It is impossible to verify complex DMA processes. Based on the above analysis, the fundamental defects of existing technologies lie in architectural design flaws (single routing table, single processing task, lack of modularity), abstraction level flaws (low abstraction level for precise periodic modeling, lack of transaction-level abstraction), synchronization mechanism flaws (static configuration, lack of real-time synchronization), and functional modeling flaws (missing special scenarios, lack of support for bidirectional traffic). These fundamental defects make it impossible for traditional methods to meet the verification needs of modern complex on-chip networks.

[0015] To address the aforementioned issues, this invention provides a UVM-based on-chip network switch verification method, thoroughly resolving these problems from three levels: architecture, algorithm, and mechanism. At the architecture level, this invention employs a multi-channel routing table mirroring mechanism, maintaining independent switch-to-node (S2N) and switch-to-switch (S2S) routing table mirrors for each channel type. This accurately models the hardware's 10 sets of routing tables, achieving 100% routing decision accuracy and reducing the false alarm rate to below 5%. A layered and decoupled processing task architecture is adopted, decomposing network behavior into 57 independent concurrent tasks. This fully utilizes the simulator's concurrency capabilities, increasing simulation speed by 5-10 times and shortening the verification cycle by 40%. A bidirectional traffic processing mechanism is employed, maintaining independent routing tables and processing logic for uplink and downlink traffic, supporting multi-chip interconnection scenarios with 100% coverage. At the algorithm level, this invention designs an intelligent routing decision algorithm that supports multiple routing modes such as S2S, S2MN, and S2QNM; it designs a descriptor pairing algorithm based on trace_id to support out-of-order arrival; it designs a 1-to-4 descriptor distribution algorithm to accurately model the special routing behavior of Quadrant Manager (QNM); and it adopts a Direct Memory Access (DMA) transaction-level modeling algorithm to automatically generate synchronization messages and read / write command sequences, achieving an optimal balance between accuracy and efficiency. At the mechanism level, this invention implements a real-time synchronization mechanism, reading the latest configuration from the CSR register before each transaction to track dynamic routing changes, achieving 100% coverage of dynamic routing scenarios; it adopts a modular design and a unified interface specification to reduce code coupling, reducing maintenance costs by 50% and expansion costs by 60%. Through these innovations, this invention improves code coverage to over 95%, functional coverage to over 98%, and bug detection capabilities by 3 times, while shortening the development cycle by 60%, reducing verification manpower costs by 40%, and reducing total costs by 40%, fundamentally improving the quality and efficiency of on-chip network verification and reducing tape-out risks.

[0016] like Figure 1 As shown, this invention provides a schematic diagram of the connection structure of a Design Under Test (DUT) based on an on-chip network switch. This invention is based on the on-chip network OCN_S5_Switch switch, which is an important switch in the on-chip system. This switch connects to the upper and lower switches and numerous nodes. In the on-chip system, this switch connects adjacent upper and lower switches and nodes such as memory nodes (MN), client nodes (CN), DMA, and quadrant node managers (QNM).

[0017] like Figure 2As shown, this invention provides a schematic diagram of the structure of an on-chip network switch verification platform based on UVM. The verification platform includes: a control status register agent (CSR_Agent), a switch-to-switch agent (S2S_Agent), a memory node agent (MN_Agent), a client node agent (CN_Agent), a reference model (RM), a scoreboard, and a coverage collector.

[0018] For example, the CSR configuration agent component interacts with the on-chip network switch to simulate real CSR register configuration behavior, and is used to configure routing tables, quality of service (QoS) parameters, flow control parameters, etc.

[0019] For example, the switch interconnection component interacts with the switch (DUT) to simulate the interconnection behavior of a real on-chip network switch. It includes five transaction types: descriptor channel agent (DESC_Agent), command channel agent (CMD_Agent), data channel agent (DATA_Agent), response channel agent (RESP_Agent), and message channel agent (MSG_Agent). It adopts a flow control mechanism based on credit, supports three virtual channels, and each direction contains multiple physical channel lanes to realize bidirectional data transmission in the east-west direction.

[0020] For example, the storage node component interacts with the storage node (MN) to simulate real storage access behavior, including four transaction types: write command, write data, read command, and read data. It adopts a credit-based flow control mechanism, supports automatic response function (Auto_resp_en=1), and uses a global transaction pool for request-response matching with a pool capacity of 512.

[0021] For example, the client node component interacts with the client node (CN) to simulate real client access behavior, including three transaction types: descriptor, peripheral block to node message, and node to peripheral block message. A credit-based flow control mechanism is used to realize bidirectional communication between the peripheral block and the client node.

[0022] For example, the reference model is used to implement the same logical functions as a device under development (DUT) such as routing decision, descriptor matching, and data forwarding, and transmits the expected results to the scoreboard.

[0023] For example, a scoreboard is used to compare the actual output of a device under test (DUT) with the expected output of a reference model, including checks on data correctness, data quantity, and data integrity.

[0024] For example, the coverage collector is implemented based on the uvm_subscriber mechanism. It receives transaction data from the monitor through the analysis port analysis_export and performs coverage sampling on key signals and fields, including various types such as descriptor descriptor, command cmd, data, response resp, and message msg.

[0025] For example, the Interface is used to connect the verification platform and the DUT.

[0026] For example, the CSR configuration agent component CSR_agent includes: CSR driver, CSR monitor CRS_monitor, CSR sequence generator CSR_sequencer, CSR adapter CSR_adapter, and CSR predictor CSR_predictor.

[0027] For example, the CSR driver (CSR_driver) requests the necessary CSR configuration sequence (CSR_sequence) from the CSR sequence generator (CSR_sequencer) and transmits the CSR configuration sequence to the on-chip network switch (DUT) via the interface. The driver supports single-write mode (csr_write_mode=0) and burst write mode (csr_write_mode=1). In single-write mode, the driver sends configuration information such as routing table entries one by one; in burst write mode, the driver sends multiple configuration items in batches, improving configuration efficiency. The driver supports a timeout detection mechanism, reporting an error when a configuration operation times out to ensure configuration reliability.

[0028] For example, the CSR monitor, CSR_monitor, monitors bus transactions on the CSR interface, captures configuration changes on input and output ports, and sends the monitored transactions to the routing table mirror module Routing_Table_Mirror and the reference model Reference_Model via the analysis port. The monitor collects the write enable signal wr_en, write address addr, and write data wdata, creates a CSR transaction csr_item, and sends it through the analysis port. The monitor supports dual-port monitoring, simultaneously monitoring configuration operations on both input and output ports to ensure configuration integrity and consistency.

[0029] For example, the CSR sequence generator CSR_sequencer, which inherits from the UVM standard sequencer uvm_sequencer, is responsible for managing and scheduling the execution of CSR configuration sequences CSR_sequence. It receives sequence requests from virtual sequences or test cases, selects the next sequence to execute through an arbitration mechanism, and passes the sequence item to the CSR driver CSR_driver. The sequence generator supports various arbitration strategies, including FIFO, priority, and random, and can handle concurrent configuration requests, ensuring the correct order and timing of register configurations. The sequence generator is tightly integrated with the register model, automating register access and synchronously updating mirror values ​​through the adapter CSR_adapter and the predictor CSR_predictor.

[0030] For example, the CSR adapter CSR_adapter, which inherits from the UVM register adapter base class uvm_reg_adapter, is responsible for protocol conversion between register operations in the register model and CSR bus transactions csr_item. The adapter converts register model read and write operations into CSR bus transactions and converts CSR bus responses back into the register model, thus decoupling the register abstraction layer from the bus protocol layer.

[0031] For example, the CSR predictor, CSR_predictor, inherits from the UVM register predictor base class uvm_reg_predictor and is used to automatically update the mirrored value of the register model based on monitored CSR bus transactions. The predictor receives bus transactions from the CSR monitor, parses the transaction address and data, updates the mirrored value of the corresponding register, and ensures that the register model is synchronized with the register state of the DUT, supporting real-time mirroring and dynamic verification of the routing table.

[0032] For example, the switch interconnect components include: a switch interconnect driver, a switch interconnect monitor, a switch interconnect sequence generator, an automatic response sequence, and a global transaction pool.

[0033] This switch interconnect driver requests transaction sequences from the sequence generator and transmits them to the DUT via the interface, implementing data transmission based on a credit flow control mechanism. The driver supports a send mode (sndr_mode=1) and a receive mode (sndr_mode=0). In send mode, the driver maintains a credit counter for each virtual channel, sending transactions only when the credit is greater than 0. It supports a maximum credit value configuration (default is 8), implementing flow control and backpressure mechanisms. In receive mode, the driver receives transactions from the DUT and returns a credit signal. The driver supports configurable transmission and credit delays, simulating the timing variations of a real system. The driver implements multi-virtual-channel concurrent processing (fork-join_none), with each virtual channel independently maintaining its queue and credit status, supporting 1-3 virtual channels and avoiding deadlock.

[0034] The switch interconnect monitor monitors bus transactions on switch interconnect interfaces, capturing valid signals and data payloads, and sending the monitored transactions to other verification components via the analysis port. During the run_phase (the core phase in the UVM verification environment used to perform dynamic simulation tasks), the monitor continuously runs the collect task, detecting valid signals each clock cycle. When a valid transaction is detected, it collects the complete data payload, creates a transaction object, and sends it via the analysis_port. The transactions collected by the monitor are used for various verification purposes: sent to the reference model for functional comparison, sent to the coverage collector for coverage statistics, sent to the scoreboard for end-to-end checks, and sent to the predictor to update the register model image values. The monitor implements a lightweight design, without performing protocol checks or data parsing, only responsible for raw data acquisition, ensuring minimal performance overhead and maximum reusability.

[0035] The switch interconnect sequence generator, inherited from the UVM standard sequencer uvm_sequencer, is responsible for managing and scheduling the execution of switch interconnect sequences. It receives sequence requests from virtual sequences or test cases, selects the next sequence to execute through an arbitration mechanism, and passes the sequence item to the driver. The sequence generator supports various arbitration strategies, including FIFO, priority, and random, and can handle concurrent transaction requests, ensuring fair scheduling of multiple virtual channels.

[0036] Automatic response sequences are used to automatically generate response transactions in receive or send modes, enabling the Agent's self-checking function. The `auto_resp_en` flag in the configuration controls whether automatic response is enabled, `pool_name` specifies the name of the global transaction pool, and `pool_capacity` specifies the transaction pool capacity (default 100, 512 storage nodes). The corresponding response sequence is automatically selected based on the component type `agnt_type`. The response sequence extracts requests from the global transaction pool and generates corresponding response transactions based on the request's address, length, ID, and other information. Configurable response latency and error injection are supported.

[0037] The global transaction pool (global_transaction_pool) is used to pass transaction information between the requesting and responding ends, enabling request-response matching and automatic response. The transaction pool uses a globally shared naming mechanism (pool_name), allowing multiple agents to access the same pool through the same pool_name, thus facilitating cross-agent transaction transmission. The pool capacity (pool_capacity) limits the number of transactions stored simultaneously; when the pool is full, new requests will be blocked, simulating backpressure in a real system. The transaction pool supports both FIFO and priority-based retrieval strategies to ensure transaction ordering and fairness. The transaction pool implements a thread-safe mechanism, supporting concurrent deposit and retrieval operations to avoid race conditions and data corruption.

[0038] The Credit flow control mechanism employs a Credit-based flow control system in the switch interconnect components to ensure data transmission reliability and system stability. The sending end maintains a Credit counter for each virtual channel, initially set to the maximum Credit value. The Credit is decremented by 1 for each transaction sent and incremented by 1 for each received Credit signal. The receiving end returns a Credit signal upon receiving a transaction, notifying the sending end that data transmission can continue. The Credit check enable flag `crdt_chk_en` controls whether Credit checks are performed. When disabled, the sending end can transmit data without restriction, suitable for special testing scenarios. The Credit flow control mechanism supports independent control at the virtual channel level, with each virtual channel having its own independent Credit counter and Credit signal, enabling fine-grained flow control.

[0039] For example, the Memory_Node Agent component is implemented based on the switch interconnect component. Through special configuration, it supports read and write operations between the memory node (MN) and the peripheral block, including: the memory node driver MN_driver, the memory node monitor MN_monitor, the memory node sequence generator MN_sequencer, the write response generation sequence write_response_sequence, and the read data generation sequence read_data_sequence.

[0040] The storage node driver, MN_driver, inherits from the switch interconnect driver, credit_base_driver. It requests storage access sequences from the storage node sequence generator and transmits them to the DUT via the interface, enabling read and write operations on the storage node. The storage node contains four types of agents: the write command agent (ocn_blk_mn_wr) operates in receive mode, receiving write commands and write data from the Block; the write response agent (ocn_mn_blk_wr) operates in send mode, sending write responses to the peripheral Block; the read command agent (ocn_mn_blk_rd) operates in send mode, sending read commands to the peripheral Block; and the read data agent (ocn_blk_mn_rd) operates in receive mode, receiving read data responses from the peripheral Block. The driver supports automatic response functionality (auto_resp_en=1), using a global transaction pool to achieve request-response matching. The pool capacity is configured to 512, ensuring support for high-capacity concurrent transactions. The driver maintains an independent credit counter and transaction queue for each storage node instance, supporting two storage node instances to achieve parallel storage access and high throughput.

[0041] The storage node monitor MN_monitor, inherited from the switch interconnect monitor credit_base_monitor, monitors bus transactions on storage node interfaces, capturing signals such as write commands, write data, read commands, and read data, and sending the monitored transactions to other verification components through the analysis port. Write command transactions collected by the monitor include fields such as address, length, ID, and virtual channel, used for subsequent response generation and data comparison. Read command transactions collected by the monitor include fields such as address, length, and ID, used for reading data generation and matching. The monitor supports transaction-level timestamp recording for performance analysis and timing checks, ensuring that storage access latency meets design specifications.

[0042] The storage node sequence generator MN_sequencer, inherited from the switch interconnection sequence generator credit_base_sequencer, is responsible for managing and scheduling the execution of storage node sequences. The sequence generator supports multiple storage access modes: sequential access (accessing storage in ascending order of address), random access (randomly selecting addresses for access), burst access (continuously accessing multiple addresses), and interleaved access (interleaving access across multiple storage nodes). The sequence generator supports configurable data modes: all-zero mode, all-one mode, ascending mode, random mode, Walking 1 mode, and Walking 0 mode, for different test scenarios and error detection. The sequence generator is tightly integrated with the global transaction pool; the transaction pool name is specified through the pool_name parameter, enabling cross-agent transaction delivery and request-response matching.

[0043] The `write_response_sequence`, of type `blk2mn_gen_wrresp_seq`, is used to automatically generate write response transactions upon receiving write commands and write data. The sequence runs continuously during the `run_phase` phase, extracting write request transactions from the global transaction pool and generating corresponding write response transactions based on information such as the request ID and virtual channel. The write response transaction includes fields such as response type, response status, and ID, and is sent to the driver via the sequence generator. The sequence supports configurable response latency to simulate write latency in a real storage system and supports error injection, allowing configuration to generate error responses with a certain probability for testing the DUT's error handling mechanism.

[0044] The `read_data_sequence`, of type `blk2mn_gen_rdresp_seq`, is used to automatically generate read data transactions upon receiving a read command. The sequence extracts read request transactions from the global transaction pool and generates corresponding read data transactions based on information such as the request address, length, ID, and virtual channel. Each read data transaction includes fields such as data payload, end flag, and ID. The data payload is read from the storage model to ensure data consistency and correctness. The sequence supports configurable read latency, simulating read latency in a real storage system, and supports multiple data return modes: single-cycle return returns all data at once, multi-cycle return returns data in multiple steps, and pipelined return supports pipelined processing of multiple read requests. The sequence supports ECC functionality, allowing configuration to inject single-bit or multi-bit errors with a certain probability for testing the DUT's ECC detection and correction capabilities.

[0045] A global transaction pool is configured, and storage node components use this pool to implement request-response matching. Write command agents and write response agents share the same transaction pool (pool_name="mn_wr_pool"). The write command agent stores received write requests into the transaction pool, and the write response agent retrieves requests from the pool and generates write responses. Read command agents and read data agents share a separate transaction pool (pool_name="mn_rd_pool". The read command agent stores sent read requests into this pool, and the read data agent retrieves requests from the pool and generates read data. The transaction pool supports transaction timeout detection; when a transaction remains in the pool for more than a threshold, a timeout error is reported to detect deadlocks and performance issues. The transaction pool also supports transaction priority management, with higher-priority transactions being retrieved and processed first.

[0046] For example, the Client_Node Agent component is implemented based on the switch interconnection component. Through special configuration, it supports message passing and data interaction between the Client Node (CN) and the switch, including: Client_Node driver (CN_driver), Client_Node monitor (CN_monitor), Client_Node sequence generator (CN_sequencer), Message_Response_Sequence, and Data_Response_Sequence.

[0047] The client node driver, CN_driver, inherits from the switch interconnection driver, credit_base_driver. It requests message and data sequences from the client node sequence generator and transmits them to the DUT via the interface, enabling message passing and data interaction between the client nodes. The client node contains several types of agents: a message sending agent (ocn_cn_msg) operates in send mode, sending messages to the switch; a message receiving agent (ocn_msg_cn) operates in receive mode, receiving message responses from the switch; a data sending agent (ocn_cn_data) operates in send mode, sending data to the switch; and a data receiving agent (ocn_data_cn) operates in receive mode, receiving data responses from the switch. The driver supports automatic response functionality (auto_resp_en=1), implementing request-response matching through a global transaction pool with a capacity of 100. The driver supports configurable message priorities and virtual channel mapping to ensure timely delivery of critical messages.

[0048] The client node monitor, CN_monitor, inherits from the switch interconnect monitor, credit_base_monitor. It monitors bus transactions on client node interfaces, capturing signals such as messages, data, and responses, and forwards the monitored transactions to other verification components via the analysis port. Message transactions collected by the monitor include fields such as message type, source node ID, destination node ID, message payload, and virtual channel, used for message routing verification and functional checks. Data transactions collected by the monitor include fields such as data payload, byte enable, end flag, and ID, used for data integrity checks and end-to-end verification. The monitor supports protocol-level checks, including credit flow control checks, virtual channel deadlock checks, and message order checks, ensuring correct protocol implementation.

[0049] The client node sequence generator, CN_sequencer, inherits from the switch interconnection sequence generator, credit_base_sequencer, and is responsible for managing and scheduling the execution of client node sequences. The sequence generator supports multiple message passing modes: unicast to a single destination node, multicast to multiple destination nodes with the same message, and broadcast to all nodes. It also supports multiple data transmission modes: streaming to continuously send large amounts of data, burst transmission to send large amounts of data in a short period, and intermittent transmission to send data intermittently. The sequence generator supports configurable message modes: control messages for system control and configuration, data messages for data transmission, synchronization messages for inter-node synchronization, and interrupt messages for interrupt notification. The sequence generator is tightly integrated with the global transaction pool, specifying the transaction pool name via the pool_name parameter, enabling cross-agent transaction delivery and request-response matching.

[0050] The message response generation sequence `message_response_sequence`, of type `cn_gen_msg_resp_seq`, is used to automatically generate a message response transaction upon receiving a message request. The sequence extracts message request transactions from the global transaction pool and generates the corresponding message response transaction based on information such as the requested message type, source node ID, and destination node ID. The message response transaction includes fields such as response type (acknowledgment / rejection), response status, and response payload. The sequence supports configurable response latency to simulate message processing latency in a real system, message filtering (configurable to respond only to messages of specific types or from specific source nodes), and error injection (configurable to generate error responses with a certain probability for testing the DUT's error handling mechanism).

[0051] The data response generation sequence `data_response_sequence`, of type `cn_gen_data_resp_seq`, is used to automatically generate a data response transaction upon receiving a data request. The sequence extracts data request transactions from the global transaction pool and generates a corresponding data response transaction based on information such as the request's address, length, ID, and virtual channel. The data response transaction includes fields such as data payload, end flag, and ID. The data payload is read from local cache or remote storage depending on the request type. The sequence supports configurable data latency, simulating data access latency in a real system, including cache hit latency and cache miss latency. The sequence supports multiple data return modes: single-time return returns all data at once, multi-time return returns data in multiple batches, pipelined return supports pipelined processing of multiple data requests, and out-of-order return supports out-of-order data return. The sequence supports data integrity checks, including CRC checksum, parity check, and ECC checksum, to ensure reliable data transmission.

[0052] A global transaction pool is configured. Client node agents use this pool for request-response matching, with a pool capacity of 100. Message sending agents and message receiving agents share the same transaction pool (pool_name="cn_msg_pool"). The message sending agent stores message requests in the transaction pool, and the message receiving agent retrieves requests from the pool and generates message responses. Data sending agents and data receiving agents share a separate transaction pool (pool_name="cn_data_pool". The data sending agent stores data requests in the transaction pool, and the data receiving agent retrieves requests from the pool and generates data responses. The transaction pool supports transaction timeout detection, priority management, and routing information recording for deadlock detection and route verification.

[0053] For example, the Reference Model is used to implement routing decision, descriptor pairing, and data forwarding functions equivalent to the on-chip network DUT, and transmits the expected results to the scoreboard. It includes: Routing Decision Module, Descriptor Pairing Module, Data Forwarding Module, DMA Transaction Modeling Module, and Routing Table Query Interface.

[0054] The Routing Decision Module is used to make routing decisions for input DMA transactions based on the configuration of the Routing Table Mirror, determining the output port of the transaction. Specifically, the Routing Decision Module supports three routing modes: S2S mode (Switch to Switch) implements switch-to-switch routing, querying the routing table based on the destination node ID to determine whether the output port is on the east or west side; S2MN mode (Switch to MemoryNode) implements switch-to-memory node routing, determining which MN instance the output goes to; and S2QNM mode (Switch to QNM) implements switch-to-quadrant management node routing, supporting a 1-to-4 descriptor distribution mechanism, copying an input descriptor and distributing it to four quadrant management nodes. Before processing each DMA transaction, the Routing Decision Module accesses the Routing Table Mirror to obtain the latest routing configuration, ensuring that the routing decision is based on the real-time routing table status and supporting validity checks of routing table entries.

[0055] The Descriptor Pairing Module is used to pair write commands (WRCMD) with write data (WRDATA) and read commands (RDCMD) with read data (RDDATA). Matching is based on trace_id and supports out-of-order pairing. Specifically, the module maintains write pairing queues and read pairing queues, each with a capacity of 512. The pairing module uses a trace_id-based matching algorithm: when a command descriptor is received, it is added to the pairing queue and its trace_id is recorded. When a data descriptor is received, a command descriptor with the same trace_id is searched in the queue to complete the pairing, generate a complete transaction, and is then removed from the queue. The pairing module supports out-of-order pairing; command and data descriptors can arrive in any order, and the module can correctly match and generate a complete transaction, resolving pairing issues caused by out-of-order network transmission. The pairing module supports timeout detection; when a descriptor remains in the queue for more than a threshold, a pairing timeout error is reported.

[0056] The Data Forwarding Module (Data_Forwarding_Module) forwards DMA transactions to the correct output port based on routing decisions, supporting multi-channel concurrent forwarding. Specifically, the Data Forwarding Module maintains multiple output queues, including an east-side output queue, a west-side output queue, a storage node output queue, and a quadrant management node output queue. Based on the output of the routing decision module, the Data Forwarding Module places transactions into the corresponding output queues: for S2S mode, it selects the east-side or west-side output queue based on the output port; for S2MN mode, it selects the corresponding MN output queue based on the MN instance ID; for S2QNM mode, it copies the transaction four times and places it into four QNM output queues. The Data Forwarding Module supports multi-channel concurrent forwarding, using the fork join_none mechanism to process multiple output queues in parallel, achieving high throughput and low latency, and supporting flow control.

[0057] The DMA transaction modeling module is used to model the transmission behavior of DMA transactions, providing a unified modeling interface for seven transaction types. Specifically, the DMA transaction modeling module provides seven modeling functions: `tx_msg` for message transaction transmission, `tx_wrcmd` for write command transaction transmission, `tx_rdcmd` for read command transaction transmission, `tx_wrdata` for write data transaction transmission, `tx_rddata` for read data transaction transmission, `tx_wrresp` for write response transaction transmission, and `tx_rdresp` for read response transaction transmission. Each modeling function receives the corresponding transaction parameters, generates a transaction object, and calls the routing decision module, descriptor pairing module, and data forwarding module to complete the routing, pairing, and forwarding of the transaction. The DMA transaction modeling module adopts an object-oriented design, defining an independent transaction class for each transaction type, inheriting from the base transaction class, achieving code reuse and extensibility, and supporting transaction randomization and serialization.

[0058] For example, the scoreboard, used to compare whether the actual output of the on-chip network DUT matches the expected output of the Reference Model, includes: Routing Checker, Pairing Checker, Data Integrity Checker, and Performance Checker.

[0059] The Routing_Checker checks the correctness of the routing decisions of the on-chip network device under test (DUT) and verifies whether transactions are correctly routed to the expected output ports. The Routing_Checker receives actual output transactions from the DMA monitor and expected output transactions from the reference model, and performs data acquisition by analyzing ports. The Routing_Checker compares the actual output ports with the expected output ports to ensure consistency and checks the correctness of the routing mode (including S2S, S2MN, S2QNM, etc.). The Routing_Checker supports an error reporting mechanism; when a routing error is detected, it records the error type, error location, actual value, expected value, and generates a detailed error report for debugging.

[0060] The Pairing Checker checks whether descriptor pairings are correct, verifying the pairing of write command WRCMD with write data WRDATA, and read command RDCMD with read data RDDATA. The Pairing Checker compares the actual trace_id of the DUT pairing with the expected trace_id of the reference model, checks if the trace_ids of WRCMD and WRDATA are consistent, and checks if the trace_ids of RDCMD and RDDATA are consistent. The Pairing Checker verifies whether the pairing order meets expectations, supports verification of out-of-order pairing scenarios, and ensures that the pairing result is correct even if commands and data arrive in different orders. The Pairing Checker detects pairing timeout errors, reporting an error when a descriptor remains in the pairing queue for more than a threshold.

[0061] The Data Integrity Checker is used to check the integrity of data transmission, verifying the correctness of data content, length, and order. It compares the actual data load output by the DUT with the expected data load of the reference model, performing a byte-by-byte comparison to detect data corruption or tampering. The Data Integrity Checker verifies the correct data length, checking if the actual transmitted data volume matches the expectation, and detecting data loss or duplication. It also verifies the correct data order, checking if data arrives in the expected sequence for channels requiring ordered transmission. Finally, the Data Integrity Checker supports byte enable checks, verifying the correctness of byte enable signals for partial write operations.

[0062] The Performance Checker is used to check performance metrics and verify whether throughput, latency, and bandwidth utilization meet design specifications. The Performance Checker measures throughput, counting the number of transactions or data transmitted per unit time to verify if design goals are met. The Performance Checker measures latency, recording the time interval from input to output for each transaction, including average latency, minimum latency, maximum latency, and latency distribution. The Performance Checker calculates bandwidth utilization, calculating the ratio of actual bandwidth used to the theoretical maximum bandwidth to identify bandwidth bottlenecks. The Performance Checker monitors queue depth, recording the real-time and peak depth of each output queue to detect congestion. The Performance Checker supports performance threshold checks, reporting warnings or errors when performance metrics exceed preset thresholds.

[0063] For example, the Coverage Collector is used to collect functional coverage and evaluate the completeness and adequacy of validations, including: Descriptor Channel Coverage Group, Command Channel Coverage Group, Data Channel Coverage Group, Response Channel Coverage Group, Message Channel Coverage Group, Memory Node Coverage Group, and Client Node Coverage Group.

[0064] The `Descriptor_Channel_Coverage` group, inherited from the `uvm_subscriber` base class, is used to collect functional coverage data for descriptor channels. The coverage group defines coverage points through `covergroup`, including: the `desc_valid` coverage point, which tracks the values ​​of valid descriptor signals; the `desc_dest_node_id` coverage point, which tracks the range of destination node IDs (0-127); and the `desc_trace_id` coverage point, which tracks the range of trace ID values. The coverage group receives transactions from the monitor via the `write` function, calls the `covergroup.sample` method to sample data, and calculates the hit rate for each coverage point.

[0065] The CommandChannelCoverage group, inherited from the uvm_subscriber base class, is used to collect functional coverage of command channels. The coverage group defines coverage points including: cmd_valid coverage point (statistics on valid command signals), cmd_vc coverage point (statistics on the virtual channel number range (0-2), cmd_dest_node_id coverage point (statistics on the destination node ID range (0-127), cmd_opcode coverage point (statistics on opcode values), and cmd_trace_id coverage point (statistics on the trace_id value range). The coverage group supports concurrent coverage collection across multiple lanes, with coverage statistics calculated independently for each channel.

[0066] The DataChannelCoverage group, inherited from the uvm_subscriber base class, is used to collect functional coverage of data channels. Specifically, the DataChannelCoverage group defines coverage points including: data_valid coverage point (value of valid signal, 0 or 1); data_payload coverage point (value range of payload); data_byte_enable coverage point (value of byte enable signal); data_last coverage point (value of end flag, 0 or 1); and data_trace_id coverage point (value range of trace_id). The coverage group supports concurrent coverage collection for multiple channels, with each channel's coverage calculated independently, ensuring that all data channel functionalities are fully tested.

[0067] The ResponseChannelCoverage group, inherited from the uvm_subscriber base class, is used to collect functional coverage of response channels. Specifically, the ResponseChannelCoverage group defines coverage point packages: the resp_valid coverage point records the values ​​of valid response signals (0 or 1), the resp_type coverage point records the values ​​of response types, including successful responses and error responses, the resp_status coverage point records the values ​​of response status, and the resp_trace_id coverage point records the range of trace_id values. The coverage group supports concurrent coverage collection for multiple channels, with each lane independently calculating coverage to verify the correctness and completeness of the response mechanism.

[0068] The MessageChannelCoverage group, inherited from the uvm_subscriber base class, is used to collect functional coverage data for message channels. The coverage points defined in the coverage group include: msg_valid coverage point (statistics on the values ​​of valid message signals), msg_vc coverage point (statistics on the range of virtual channel numbers (0-2)), msg_dest_node_id coverage point (statistics on the range of destination node IDs (0-127)), msg_type coverage point (statistics on the values ​​of message types), and msg_trace_id coverage point (statistics on the range of trace_id values). The coverage group verifies the functional integrity of the message passing mechanism.

[0069] The Memory_Node_Coverage group, inherited from the uvm_subscriber base class, is used to collect the functional coverage of storage nodes. Specifically, the Memory_Node_Coverage group defines the following coverage points: blk_mn_valid coverage point counts the valid signal values ​​from the peripheral block to the MN; mn_blk_valid coverage point counts the valid signal values ​​from the MN to the peripheral block; wr_resp_valid coverage point counts the valid write response signal values; and rd_data_valid coverage point counts the valid read data signal values.

[0070] The Client_Node_Coverage group, inherited from the uvm_subscriber base class, is used to collect the functional coverage of client nodes. Specifically, the Client_Node_Coverage group defines coverage points including: the b2n_desc_valid coverage point, which counts the valid signal values ​​from peripheral blocks to Node descriptors; the b2n_msg_valid coverage point, which counts the valid signal values ​​from peripheral blocks to Node messages; and the n2b_msg_valid coverage point, which counts the valid signal values ​​from Node to peripheral blocks messages. The coverage group verifies the integrity of the client node's message passing and descriptor transmission functions.

[0071] based on Figure 1 The DUT and shown Figure 2 The verification platform shown is as follows: Figure 3 As shown, this invention provides a UVM-based on-chip network switch verification method. The method includes steps S101-S104.

[0072] S101. Generate the test transaction in the verification process and send it to the Design Under Test (DUT) of the on-chip network switch and the reference model of the UVM verification platform.

[0073] As one possible implementation, step S101 can be specifically implemented as S1011-S1012.

[0074] The S1011 and UVM verification platform generate transactions to be tested through the proxy component.

[0075] In some embodiments, the proxy components include a switch interconnect proxy component, a storage node proxy component, and a client node proxy component, and the transaction to be tested is one or more of the following direct memory access (DMA) transactions: message MSG, write command WRCMD, read command RDCMD, write data WRDATA, read data RDDATA, write response WRRESP, and read response RDRESP.

[0076] The S1012 UVM verification platform sends the transaction to be tested to both the DUT and the reference model simultaneously via the interface.

[0077] In some embodiments, the interface is matched one-to-one with the DUT's switch interconnect interface, storage node interface, and client node interface.

[0078] S102. Before processing the test transaction, the control reference model obtains the latest routing table in the DUT and synchronizes it to the routing table mirroring module built into the reference model, so that the routing table of the reference model and the DUT remains consistent.

[0079] As one possible implementation, step S102 can be specifically implemented as S1021-S1022.

[0080] Before processing the transaction to be tested, the S1021 and UVM verification platform control reference model reads the DUT's CSR register through the CSR configuration agent component using a backdoor access method to obtain the latest real-time updated routing table in the DUT.

[0081] S1022. Synchronize the latest routing table to the routing table mirroring module built into the reference model, update the routing table data in the routing table mirroring module, and achieve real-time consistency between the routing table mirror and the hardware routing table of the DUT.

[0082] S103. The control reference model, based on the latest routing table, performs concurrent processing of receiving transactions to be tested, routing decisions based on routing table mirroring, descriptor pairing, and data forwarding, and outputs verification results.

[0083] As one possible implementation, step S103 can be specifically implemented as S1031-S1032.

[0084] S1031, the UVM verification platform control reference model starts a multi-level concurrent processing mode, performs pipelined concurrent processing on the transactions to be tested based on the latest routing table, and obtains the concurrent processing results.

[0085] The multi-level concurrent processing mode includes multiple levels of concurrent task layers, and each concurrent task layer includes multiple concurrent tasks.

[0086] For example, step S1031 can be implemented as steps A1-A5 as follows.

[0087] A1. The first-level transaction receiving layer receives the transaction to be tested through any one of the multiple concurrent tasks and forwards it to the routing decision layer.

[0088] A2. The second-layer routing decision layer uses any one of the multiple concurrent tasks to make routing decisions based on the routing table mirroring module, determines the routing decision result of the transaction to be tested, and forwards it to the descriptor pairing layer. The routing decision result includes the output port and transmission path.

[0089] A3. The third-layer descriptor pairing layer uses any one of the multiple concurrent tasks and a hash table out-of-order pairing algorithm based on tracking identifiers to complete the descriptor pairing of write commands and write data, and read commands and read data, generating a complete transaction data packet and forwarding it to the data forwarding layer.

[0090] A4. The fourth-layer data forwarding layer forwards the complete transaction data packets of the transaction under test through any one of the multiple concurrent tasks based on the routing decision results. For transactions in the S2QNM routing mode, the QNM descriptors of quadrant node managers from 1 to 4 are distributed based on the load balancing strategy.

[0091] A5. The fifth layer output layer integrates and encapsulates the concurrent processing results based on the routing decision results, complete transaction data packets, and data forwarding status of the data forwarding layer from any concurrent task, and then outputs them.

[0092] S1032. Control the reference model to integrate and process concurrent results to generate verification results, and send the verification results to the scoreboard of the UVM verification platform.

[0093] S104. Receive and compare the verification results of the reference model with the actual output results of the DUT to obtain the comparison verification results and realize the verification of the transaction to be tested.

[0094] As one possible implementation, step S104 can be specifically implemented as S1041-S1044.

[0095] S1041, the UVM verification platform receives the verification results output by the reference model and the actual output results fed back by the DUT through the scoreboard.

[0096] S1042. Based on the verification results and actual output results, the scoreboard performs routing checks, pairing checks, data integrity checks, and performance checks to obtain multi-dimensional comparison results.

[0097] Among them, the routing check verifies whether the output port and routing mode of the routing decision are correct; the pairing check verifies whether the tracking identifiers of the descriptor pairing match; the data integrity check compares the data content, length, and order byte by byte to see if they are consistent; and the performance check verifies whether the throughput, latency, and bandwidth utilization meet the design specifications.

[0098] S1043. If the multi-dimensional comparison results are consistent across all dimensions, then a valid comparison verification result is generated.

[0099] S1044. If any dimension of the multi-dimensional comparison results is inconsistent, a verification failure result will be generated, and an environment error message will be triggered.

[0100] As one possible implementation, steps B1-B4 are included after step S1044.

[0101] B1. The UVM verification platform receives test transaction data from the UVM verification platform's monitor through the analysis port via the UVM subscriber mechanism, based on the coverage collector.

[0102] In some embodiments, the transaction data to be tested includes transaction type, routing mode, transport port, trace identifier, and data length information.

[0103] B2. The coverage collector performs synchronous statistics on the functional coverage and code coverage of the on-chip network switch based on the test transaction data to obtain coverage data.

[0104] Functional coverage includes coverage of descriptor channels, command channels, data channels, response channels, message channels, storage nodes, and client nodes. Code coverage includes line coverage, branch coverage, condition coverage, and state machine coverage.

[0105] B3. The coverage collector performs real-time statistics and storage of coverage data to form the coverage collection results of the verification process of the transaction to be tested.

[0106] B4. Based on the coverage data collection results and the comparison verification results, generate the single verification result of the transaction to be tested.

[0107] This invention provides a UVM-based on-chip network switch verification method. The method synchronously sends the transaction to be tested to both the Device Under Test (DUT) and a reference model, ensuring that both are processed in parallel under the same stimulus, thus guaranteeing the accuracy of the verification comparison. Simultaneously, before processing the transaction, the reference model obtains the latest routing table from the DUT and synchronizes it to the routing table mirroring module, achieving real-time consistency between the two routing tables. This completely avoids false alarms caused by inconsistent routing configurations, significantly improving the reliability of the verification results. Furthermore, the reference model performs concurrent processing of the entire process of transaction execution—receiving, routing decision-making, descriptor pairing, and data forwarding—utilizing the multi-threading capabilities of the simulator to shorten the simulation time for transaction processing, solving the inefficiency problem of traditional verification methods and achieving a dual optimization of verification accuracy and efficiency.

[0108] Optionally, the UVM-based on-chip network switch verification method provided in this embodiment of the invention further includes steps S201-S202 before step S101.

[0109] S201, the UVM verification platform configures its own routing table parameters and supported routing modes, and generates a routing table to be configured.

[0110] In some embodiments, the routing modes include inter-switch routing S2S, switch-to-storage node routing S2MN, and switch-to-quadrant node manager routing S2QNM.

[0111] S202, the UVM verification platform uses the Control Status Register (CSR) to configure the agent component to send the routing table to be configured to the DUT and reference model, thus completing the initial routing configuration of the DUT and reference model.

[0112] Thus, by pre-configuring the routing parameters of the UVM verification platform and uniformly distributing the initial routing table to the Design Under Test (DUT) and the reference model, the present invention can ensure that both parties have consistent initial routing configurations before verification begins, avoiding abnormal verification results due to inconsistent initial routing information. At the same time, it reduces repetitive configuration operations during the verification process, simplifies the verification process, lays a stable foundation for subsequent real-time synchronization of routing tables and concurrent transaction verification, and further improves the overall verification efficiency and reliability.

[0113] Optionally, the UVM-based on-chip network switch verification method provided in this embodiment of the invention further includes steps S301-S304 after step S104.

[0114] S301. Obtain the single verification result of multiple transactions to be tested.

[0115] In some embodiments, the multiple transactions to be tested include random test transactions and targeted test transactions.

[0116] S302. Perform a comprehensive analysis on the comparison verification results and coverage collection results in the single verification results of multiple transactions to be tested, and obtain a comprehensive analysis result.

[0117] In some embodiments, the comprehensive analysis results include validation pass rate, functional coverage compliance rate, and code coverage compliance rate.

[0118] S303. If the comprehensive analysis results indicate that the pass rate is not up to standard or the coverage does not reach the preset target, then add targeted test cases and continue to execute the verification process until the pass rate meets the standard and the coverage reaches the preset target.

[0119] S304. If the comprehensive analysis results show that the verification pass rate meets the standard and the coverage rate reaches the preset target, then the overall verification of the on-chip network switch is completed and a comprehensive verification report is generated.

[0120] Thus, this invention can comprehensively evaluate the completeness of verification by analyzing the pass rate and coverage of multiple verification results. When the pass rate or coverage is not up to standard, it can automatically supplement targeted test cases, accurately fill verification gaps, avoid invalid repeated verification, and while ensuring the accuracy and reliability of verification results, it can quickly converge the verification process, efficiently complete the overall verification, and generate a standardized report.

[0121] For example, based on Figure 1 The DUT and shown Figure 2 The verification platform shown is as follows: Figure 4 , Figure 5 and Figure 6 As shown, the on-chip network switch verification method provided by the present invention is as described in steps 1 to 11.

[0122] Step 1, Configure verification environment parameters: In the configuration file of the verification platform, set the number of routing table groups to 10, the number of routing table entries in each group to 64, and the total number of routing table entries to 640. The supported routing modes are S2S, S2MN, and S2QNM. The supported DMA transaction types are message (MSG), write command (WRCMD), read command (RDCMD), write data (WRDATA), read data (RDDATA), write response (WRRESP), and read response (RDRESP).

[0123] Number of switch interconnect agents: 52, including 4 descriptor channel agents, 20 command channel agents, 16 data channel agents, 8 response channel agents, and 4 message channel agents; Number of storage node agents: 8, including 2 write command agents, 2 write data agents, 2 read command agents, and 2 read data agents; Number of client node agents: 3, including 1 descriptor agent, 1 peripheral (Block) to node message agent, and 1 node to peripheral (Block) message agent; Number of CSR configuration agents: 1; Number of virtual channels: 3 (VC_NUM=0 / 1 / 2); Number of QNM nodes: 4; Pairing timeout: 1000ns; Verification target coverage: 100%.

[0124] Step 2, Initialize Routing Table Configuration: The CSR configuration proxy component sends the routing table configuration to the design-under-test (DUT) of the network-on-chip, configuring the destination node ID, routing mode, output port, and validity flag for each routing table entry. The CSR monitor monitors the CSR configuration data and transmits it to the routing table mirroring module, which updates the internal mirrored routing table.

[0125] For example, the CSR configuration agent component sends routing table configurations to the OCN_S5_Switch (DUT). Taking routing table group 0 as an example, the configuration is as follows: Routing table entry 0: dest_node_id=0x10, route_mode=S2S, Desc_port=0, qos_priority=0, valid=1; Routing table entry 1: dest_node_id=0x11, route_mode=S2S, output_port=1, qos_priority=1, valid=1; Routing table entry 2: dest_node_id=0x12, route_mode=S2MN, output_port=2, qos_priority=2, valid=1; Routing table entry 3: dest_node_id=0x13, route_mode=S2QNM, output_port=3, qos_priority=3, valid=1; The configurations of the remaining routing table entries are similar. The CSR monitor monitors the CSR configuration data and transmits it to the routing table mirroring module, which then updates the routing table of its internal mirror.

[0126] Step 3, connect the verification platform and the on-chip network DUT via the interface: connect the component instances of the verification platform and the on-chip network switch (DUT) via the interface, including the descriptor channel component, command channel component, data channel component, response channel component, and message channel component of the switch interconnection component; the write command component, write data component, read command component, and read data component of the storage node; the descriptor component of the client node; the message component from a function block to a node; and the message component from a node to a function block.

[0127] Step 4, run the switch interconnection verification process: The descriptor channel component of the switch interconnection component generates routing descriptor transactions; the command channel component generates read / write command transactions; the data channel component generates data payload transactions; the response channel component generates response transactions; the message channel component generates message transactions; all switch interconnection components adopt the credit flow control mechanism, the descriptor channel, command channel, and message channel support 3 virtual channels (VC_NUM=3), the DMA monitor monitors transaction transmission and triggers the real-time synchronization mechanism, the reference model accesses and reads the DUT's CSR register through the backdoor to obtain the latest routing table configuration, the routing table mirroring module updates the internal mirror and sets the synchronization completion flag, and the reference model uses the latest routing table to make routing decisions.

[0128] For example, running random test cases on the verification platform involves using the switch interconnect proxy component, storage node proxy component, and client node proxy component to generate random transactions and transmit them to the DUT.

[0129] Step 4.1: The descriptor channel agent of the switch interconnection agent component generates a route descriptor transaction using the `tx_msg` function: `desc_trans = tx_msg(src_node=0x01, dest_node=0x10, msg_data=512'hABCD_EF01_2345_6789_..., qos_level=3'b010)`. Step 4.2: The command channel agent of the switch interconnection agent component generates a write command transaction using the `tx_wrcmd` function: `wrcmd_trans = tx_wrcmd(src_node=0x01, dest_node=0x10, wr_addr=64'h0000_1000, wr_length=16'h0040, qos_level=3'b010)`. The `trace_id` of `wrcmd_trans` is automatically generated as `32'h1234_5678`. Step 4.3: The data channel agent of the switch interconnect agent component generates write data transactions using the `tx_wrdata` function: `wrdata_trans = tx_wrdata(cmd_trace_id=32'h1234_5678, wr_data=512'hABCD_EF01_2345_6789_...)`. Step 4.4: The driver of the switch interconnect agent component transmits descriptor transactions, command transactions, and data transactions to the OCN_S5_Switch (DUT) through the interface. Step 4.5: The DMA monitor monitors transaction transmissions. Upon detecting a new DMA transaction, it triggers a synchronization request signal. Step 4.6: After receiving the synchronization request signal, the reference model triggers a real-time synchronization mechanism, accessing and reading the CSR register of the OCN_S5_Switch (DUT) through a backdoor to obtain the latest routing table configuration. Specifically, read routing table entry 0 of uplink routing table group 0: addr = 0x1000 + 0 * 256 + 0 * 4 = 0x1000, reg_value = backdoor_read(0x1000) = 32'h0001_0010, and parse reg_value to obtain: dest_node_id=8'h10, route_mode=2'b00(S2S), output_port=4'h0, qos_priority=3'b000, valid=1'b1. Step 4.7: The routing table mirroring module updates the internal mirror's routing table, sets the synchronization completion flag, and the reference model uses the latest routing table for routing decisions.

[0130] Step 5, run the storage node verification process: The write command agent of the storage node component generates a write command from Block to MN; the write data agent generates a write data transaction from MN to Block; the read command agent generates a read command transaction from MN to Block; the read data agent generates a read data response transaction from Block to MN; all storage node agents adopt the Credit flow control mechanism, support automatic response function (auto_resp_en=1), use a global transaction pool for request-response matching, the pool capacity is 512, the DMA monitor monitors the storage node transaction transmission, the reference model descriptor pairing module pairs write commands with write data and read commands with read data based on the trace identifier trace_id, and performs subsequent processing after successful pairing.

[0131] For example, the storage node verification process is as follows: Step 5.1: The write command agent of the storage node agent component generates a write command transaction from the peripheral device (Block) to the storage node, which is transmitted to the DUT through two agent instances, using a credit flow control mechanism and supporting automatic response (auto_resp_en=1). Step 5.2: The write data agent of the storage node agent component generates a write data transaction from the storage node to the peripheral device (Block), which is transmitted to the DUT through two agent instances. Step 5.3: The DMA monitor monitors the write command transaction and adds it to the write command descriptor hash table wrcmd_hash[trace_id]. Step 5.4: The DMA monitor monitors the write data transaction and triggers the descriptor pairing module, which searches for a matching write command transaction in wrcmd_hash based on trace_id. Step 5.5: If a matching write command transaction is found, pairing is performed immediately.

[0132] Step 6, run the client node verification process: The client node agent's descriptor agent generates a descriptor information transaction from the block to the client node and transmits it to the DUT through one agent instance; the block-to-node message agent generates a message transaction from the block to the client node and transmits it to the DUT through one agent instance; the node-to-block message agent generates a message transaction from the client node to the block and transmits it to the DUT through one agent instance; all client node agents adopt the credit flow control mechanism, the DMA monitor monitors the client node transaction transmission, and the reference model performs routing decisions and data forwarding.

[0133] For example, the client node verification process is as follows: Step 6.1: The client node proxy component's descriptor agent generates a descriptor information transaction from the peripheral (Block) to the client node, which is transmitted to the DUT through one agent instance. Step 6.2: The client node proxy component's peripheral (Block) to node message agent generates a message transaction from the Block to the client node, which is transmitted to the DUT through one agent instance. Step 6.3: The client node proxy component's node to Block message agent generates a message transaction from the client node to the peripheral (Block), which is transmitted to the DUT through one agent instance.

[0134] Step 7: Run the Direct Memory Access (DMA) transaction-level modeling process: Use the seven transaction-level modeling functions provided by the DMA transaction modeling module to generate DMA transactions, including the tx_msg function for modeling message transactions, the tx_wrcmd function for modeling write command transactions, the tx_rdcmd function for modeling read command transactions, the tx_wrdata function for modeling write data transactions, the tx_rddata function for modeling read data transactions, the tx_wrresp function for modeling write response transactions, and the tx_rdresp function for modeling read response transactions. The drivers of the switch interconnect agent, storage node agent, and client node agent send transactions to the DUT in sequence. The DMA monitor monitors the response transactions and checks the response status.

[0135] For example, the concurrent task architecture process is as follows: Step 7.1: The reference model starts 57 concurrent tasks. The 20 tasks in the Layer 1 transaction receiving layer receive uplink and downlink transactions from the switch interconnect agent, storage node agent, and client node agent from the DMA monitor. Step 7.2: The 20 tasks in the Layer 2 routing decision layer perform routing decisions, query the routing table mirror module, and obtain routing information: output_port, route_mode, and qos_priority. Step 7.3: The 10 tasks in the Layer 3 descriptor pairing layer perform write descriptor pairing and read descriptor pairing, based on trace_id matching. Step 7.4: The 5 tasks in the Layer 4 data forwarding layer perform data forwarding, merging command descriptor and data descriptor information. Step 7.5: The 2 tasks in the Layer 5 result output layer send the forwarded transactions to the scoreboard.

[0136] Step 8, Run the concurrent task architecture process: The reference model starts 57 concurrent tasks. The 20 tasks in the first layer transaction receiving layer receive uplink and downlink transactions from the switch interconnect components, storage node components, and client node components from the DMA monitor; the 20 tasks in the second layer routing decision layer perform routing decisions and query the routing table mirror module; the 10 tasks in the third layer descriptor pairing layer perform write descriptor pairing and read descriptor pairing; the 5 tasks in the fourth layer data forwarding layer forward data and merge command descriptor and data descriptor information; the 2 tasks in the fifth layer result output layer send the forwarded transactions to the scoreboard.

[0137] For example, the QNM node distribution process is as follows: Step 8.1: The message channel Agent of the switch interconnection agent component generates a transaction for the S2QNM routing mode: msg_trans = tx_msg(src_node=8'h01, dest_node=8'hFF, msg_data=512'h1234_5678_..., qos_level=3'b010); msg_trans.route_mode =S2QNM. Step 8.2: The reference model detects route_mode=S2QNM and triggers the QNM distributor. Step 8.3: The QNM distributor updates the QNM node status and reads the queue depth: qnm_status[0].queue_depth=50, qnm_status[1].queue_depth=100, qnm_status[2].queue_depth=150, qnm_status[3].queue_depth=80. Step 8.4: The QNM distributor selects four target nodes according to the load balancing strategy, sorting them in ascending order of queue depth: target_nodes=[0, 3, 1, 2]. Step 8.5: The QNM distributor creates four distribution descriptors, setting the same trace_id and different dest_node_ids. Step 8.6: The QNM distributor sends the four distribution descriptors to the corresponding QNM nodes.

[0138] Step 9: Run the Quadrant Node Manager (QNM) node distribution process: The message channel agent (Msg_Agent) and descriptor channel agent (Desc_Agent) of the switch interconnect component generate a transaction for the switch to quadrant node manager (S2QNM) routing mode. After the reference model detects that the routing mode is route_mode=S2QNM, it triggers the QNM distributor. The QNM distributor updates the QNM node status, including queue depth and congestion status. According to the load balancing strategy, it selects 4 target nodes, creates 4 distribution descriptors, sets the same trace ID (trace_id) and different destination node IDs (dest_node_id), and sends the 4 distribution descriptors to the corresponding QNM nodes. The panel verifies that all 4 QNM nodes have received the descriptors and that the trace_id is the same and the distribution index is correct.

[0139] For example, the scoreboard performs multi-dimensional comparison and verification: Step 9.1: The routing checker checks whether the routing decisions of the switch interconnect components, storage node components, and client node components are correct, comparing output ports and routing modes. Step 9.2: The pairing checker checks whether the descriptor pairing of the storage node components is correct, verifying that the write command matches the trace_id of the write data, and that the read command matches the trace_id of the read data. Step 9.3: The data integrity checker checks the integrity of all data transmissions, comparing data content byte by byte, verifying data length, and checking data order. Step 9.4: The performance checker checks performance metrics, measuring throughput, latency, and bandwidth utilization.

[0140] Step 10: Run the multi-dimensional comparison verification of the scoreboard: The scoreboard receives the expected output of the reference model and the actual output of the DUT collected by the DMA monitor and performs a multi-dimensional comparison check. The routing checker checks whether the routing decisions of the switch interconnect components, storage node components, and client node components are correct, including output ports and routing modes. It also checks whether the descriptor pairing of the storage node components is correct, including matching the trace_id of write commands with the trace_id of write data, matching the trace_id of read commands with the trace_id of read data, and the pairing order. It also checks the integrity of all received data transmissions, including data content, data length, data order, latency, and bandwidth utilization. If any mismatch is found, the environment will report an error, and the simulation will end upon receiving the error.

[0141] For example, the coverage collector collects functional coverage and code coverage: Step 10.1, Functional coverage includes descriptor channel coverage, command channel coverage, data channel coverage, response channel coverage, message channel coverage for switch interconnect components; write command coverage, write data coverage, read command coverage, and read data coverage for storage node components; and descriptor coverage, message coverage, routing table coverage, and routing mode coverage for client node components. Step 10.2, Code coverage includes line coverage, branch coverage, condition coverage, and state machine coverage.

[0142] Step 11, Coverage Collection: The coverage collector continuously collects code coverage data. Code coverage includes line coverage, branch coverage, condition coverage, and state machine coverage.

[0143] Step 12, determine if the coverage reaches 100%: if the coverage reaches 100%, the verification is complete; if the coverage does not reach 100%, add targeted test cases to improve the coverage and continue running the test cases.

[0144] Step 13, verification complete.

[0145] This invention proposes a UVM-based verification platform and method for on-chip network switches. In on-chip network architectures, switch interconnect interfaces are commonly used as data buses due to their high bandwidth, low latency, and burst transmission capabilities; furthermore, CSR buses are commonly used as control buses due to their low power consumption and small area overhead. To improve the versatility and scalability of the verification platform, the proposed platform includes a CSR configuration proxy component, a switch interconnect proxy component, a storage node proxy component, and a client node proxy component, used to interact with the on-chip network switch (DUT) and simulate real bus behavior. The platform can be customized according to verification requirements, including configurations for multiple routing modes (S2S, S2MN, S2QNM), and supports verification of multiple transaction types such as MSG (message), WRCMD (write command), RDCMD (read command), WRDATA (write data), RDDATA (read data), WRRESP (write response), and RDRESP (read response). When verifying different on-chip network switches (DUTs), only the corresponding routing table needs to be configured according to the DUT's functions, without requiring large-scale modifications to the framework or structure of the verification platform. This reduces the workload of verification engineers, shortens the verification cycle, and greatly reduces verification costs.

[0146] In summary, the present invention has the following technical effects: (1) The verification platform proposed in this invention includes a CSR configuration agent component, a switch interconnection agent component (including 52 instances of descriptor channel agent, command channel agent, data channel agent, response channel agent, and message channel agent), a storage node agent component (including 8 instances of write command agent, write data agent, read command agent, and read data agent), and a client node agent component (including 3 instances of descriptor agent, block to node message agent, and node to block message agent). It has strong versatility when verifying different on-chip network switches. (2) The verification platform proposed in this invention can be customized according to verification requirements, supporting custom routing table mirroring (20 groups of routing tables with a total of 1280 routing table entries), custom descriptor pairing algorithm (hash table pairing based on trace_id), custom task concurrency architecture (5 layers with 57 concurrent tasks), custom QNM node distribution strategy (round-robin strategy, load balancing strategy, priority strategy), and custom Credit flow control parameters (supporting 1-3 virtual channels), which greatly improves the flexibility and scalability of the verification platform. (3) The verification platform proposed in this invention includes multiple Agent types and transaction modeling functions (tx_msg, tx_wrcmd, tx_rdcmd, tx_wrdata, tx_rddata, tx_wrresp, tx_rdresp), which can simulate transaction transmission under multiple routing modes (S2S, S2MN, S2QNM). When verifying different on-chip network switches, it is only necessary to configure the corresponding routing table and Agent parameters according to the functions supported by the on-chip network switch, without making large-scale changes to the framework or structure of the verification platform, reducing the workload of verification engineers, shortening the verification cycle, and greatly reducing the verification cost.

[0147] This invention solves the problem of complex on-chip network verification. In this invention, (1) multi-channel routing table mirroring mechanism - 20 groups of routing tables, 1280 table entries, 8-bit encoding; (2) real-time synchronization mechanism - read CSR before each transaction, 0-cycle synchronization delay; (3) layered decoupled processing task architecture - 57 concurrent tasks, 5-layer architecture; (4) intelligent routing decision algorithm - S2S / S2N; (5) descriptor pairing algorithm - double loop pairing based on trace_id; (6) 1 to 4 descriptor distribution algorithm - QNM node distribution, supporting broadcast mode; (7) DMA transaction-level modeling - tx_msg / tx_wrcmd / tr_rdcmd, etc.; (8) bidirectional traffic processing mechanism - independent uplink and downlink routing tables and processing tasks.

[0148] This invention presents a UVM-based on-chip network switch verification platform architecture, comprising a CSR configuration agent component, a switch interconnection agent component, a storage node agent component, a client node agent component, a reference model, a scoreboard, and a coverage collector. A real-time routing table synchronization mechanism is implemented: 640 routing table entries are synchronized in real-time by accessing the DUT's CSR register via a backdoor, resolving the accuracy issue of dynamic routing table configuration verification. A hash table-based descriptor out-of-order pairing algorithm is used: using trace_id as the key, out-of-order pairing of write commands and write data, and read commands and read data is achieved. The Reference_model features a 5-layer, 57-task concurrent verification architecture: a pipeline structure of transaction reception → routing decision → descriptor pairing → data forwarding → result output, achieving concurrent processing through message queue communication. A high-level DMA transaction modeling function encapsulates the generation of 7 DMA transaction types: message type (MSG), write command (WRCMD), read command (RDCMD), write data (WRDATA), read data (RDDATA), write response (WRRESP), and read response (RDRESP). QNM node load balancing distribution mechanism: Supports three descriptor distribution strategies: round-robin, weighted round-robin, and least connections (distributing 1 descriptor to 4 QNM nodes). This invention provides a method for real-time verification of dynamic routing, achieving 100% coverage of dynamic routing scenarios; bidirectional traffic verification via multi-chip interconnection, increasing coverage from 0-30% to 96%; achieving the best balance between accuracy and efficiency—100% accuracy + 5-10 times speed; and zero DPI interface overhead—implemented natively in SystemVerilog.

[0149] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A UVM-based on-chip network switch verification method, characterized in that, Applied to the Universal Validation Methodology (UVM) validation platform, the method includes: Generate the test transactions during the verification process and send them to the Design Under Test (DUT) of the on-chip network switch and the reference model of the UVM verification platform; Before processing the test transaction, the control reference model obtains the latest routing table in the DUT and synchronizes it to the routing table mirroring module built into the reference model to keep the routing table of the reference model consistent with that of the DUT. The control reference model, based on the latest routing table, performs concurrent processing of receiving the transaction to be tested, routing decision based on the routing table mirror, descriptor pairing, and data forwarding, and outputs the verification results. The verification results of the reference model and the actual output results of the DUT are received and compared to obtain the comparison verification results, thereby realizing the verification of the transaction to be tested.

2. The UVM-based network-on-chip switch verification method of claim 1, wherein, Before generating the test transaction in the verification process and sending it to the reference model of the Design Under Test (DUT) and UVM verification platform of the on-chip network switch, the process also includes: The UVM verification platform configures its own routing table parameters and supported routing modes, and generates a routing table to be configured. The routing modes include inter-switch routing S2S, switch-to-storage node routing S2MN, and switch-to-quadrant node manager routing S2QNM. The UVM verification platform uses the Control Status Register (CSR) to configure the agent component to send the routing table to be configured to the DUT and the reference model, thus completing the initial routing configuration of the DUT and the reference model.

3. The UVM-based network-on-chip switch verification method of claim 1, wherein, The reference model for generating the test transaction during the verification process and sending it to the Design Under Test (DUT) and UVM verification platform of the on-chip network switch includes: The UVM verification platform generates a test transaction through a proxy component, which includes a switch interconnect proxy component, a storage node proxy component, and a client node proxy component. The test transaction is one or more of the following direct memory access (DMA) transactions: message MSG, write command WRCMD, read command RDCMD, write data WRDATA, read data RDDATA, write response WRRESP, and read response RDRESP. The UVM verification platform sends the test transaction to both the DUT and the reference model simultaneously through an interface, which is matched one-to-one with the DUT's switch interconnect interface, storage node interface, and client node interface.

4. The UVM-based on-chip network switch verification method according to claim 1, characterized in that, Before processing the test transaction, the control reference model obtains the latest routing table in the DUT and synchronizes it to the routing table mirroring module built into the reference model to ensure that the routing table of the reference model and the DUT is consistent, including: Before processing the transaction to be tested, the UVM verification platform control reference model reads the DUT's CSR register through the CSR configuration agent component using a backdoor access method to obtain the latest real-time updated routing table in the DUT. The latest routing table is synchronized to the routing table mirroring module built into the reference model, and the routing table data in the routing table mirroring module is updated to achieve real-time consistency between the routing table mirror and the hardware routing table of the DUT.

5. The UVM-based on-chip network switch verification method according to claim 1, characterized in that, The control reference model, based on the latest routing table, performs concurrent processing of receiving the test transaction, routing decisions based on routing table mirroring, descriptor pairing, and data forwarding, and outputs verification results, including: The UVM verification platform control reference model starts a multi-level concurrent processing mode, performs pipelined concurrent processing on the transactions to be tested based on the latest routing table, and obtains concurrent processing results; wherein, the multi-level concurrent processing mode includes multiple levels of concurrent task layers, and each concurrent task layer includes multiple concurrent tasks. The control reference model integrates the concurrent processing results to generate verification results, and sends the verification results to the scoreboard of the UVM verification platform.

6. The UVM-based on-chip network switch verification method according to claim 5, characterized in that, The UVM verification platform control reference model initiates a multi-level concurrent processing mode, performs pipelined concurrent processing on the transactions to be tested based on the latest routing table, and obtains concurrent processing results, including: The first-level transaction receiving layer receives the transaction to be tested from any one of the multiple concurrent tasks and forwards it to the routing decision layer; The second-layer routing decision layer uses any one of the multiple concurrent tasks to make routing decisions based on the routing table mirroring module, determines the routing decision result of the transaction to be tested, and forwards it to the descriptor pairing layer. The routing decision result includes the output port and the transmission path. The third-layer descriptor pairing layer uses any one of the multiple concurrent tasks and a hash table out-of-order pairing algorithm based on tracking identifiers to complete the descriptor pairing of write commands and write data, and read commands and read data, generating a complete transaction data packet and forwarding it to the data forwarding layer. The fourth data forwarding layer forwards the complete transaction data packets of the transaction under test through any one of the multiple concurrent tasks, based on the routing decision results. For transactions in the S2QNM routing mode, it implements the distribution of quadrant node manager QNM descriptors from 1 to 4 based on the load balancing strategy. The fifth layer, the result output layer, integrates and encapsulates the concurrent processing results based on the routing decision results, the complete transaction data packet, and the data forwarding status of the data forwarding layer from any concurrent task, and then outputs them.

7. The UVM-based on-chip network switch verification method according to claim 1, characterized in that, The process of receiving and comparing the verification results of the reference model with the actual output results of the DUT to obtain the comparison verification results, thereby realizing the verification of the transaction to be tested, includes: The UVM validation platform receives the validation results output by the reference model and the actual output results fed back by the DUT through the scoreboard; Based on the verification results and actual output results, the scoreboard performs routing checks, pairing checks, data integrity checks, and performance checks to obtain multi-dimensional comparison results. Among them, the routing check verifies whether the output port and routing mode of the routing decision are correct; the pairing check verifies whether the tracking identifiers of the descriptor pairing match; the data integrity check compares the data content, length, and order byte by byte to see if they are consistent; and the performance check verifies whether the throughput, latency, and bandwidth utilization meet the design specifications. If the multi-dimensional comparison results are consistent across all dimensions, then a valid comparison verification result is generated. If any dimension of the multi-dimensional comparison results is inconsistent, a verification failure result will be generated, and an environment error message will be triggered.

8. The UVM-based on-chip network switch verification method according to claim 1, characterized in that, The process of receiving and comparing the verification results of the reference model with the actual output results of the DUT to obtain the comparison verification results and realize the verification of the transaction to be tested also includes: The UVM verification platform uses a coverage collector based on the UVM subscriber mechanism to receive test transaction data from the UVM verification platform's monitor through an analysis port; the test transaction data includes transaction type, routing mode, transmission port, trace identifier, and data length information; The coverage collector performs synchronous statistics on the functional coverage and code coverage of the on-chip network switch based on the test transaction data to obtain coverage data. The functional coverage includes the coverage of descriptor channels, command channels, data channels, response channels, message channels, storage nodes, and client nodes. The code coverage includes line coverage, branch coverage, condition coverage, and state machine coverage. The coverage collector performs real-time statistics and storage of coverage data, forming the coverage collection results for the current verification process of the transaction to be tested; Based on the coverage data collection results and the comparison verification results, a single verification result for the transaction to be tested is generated.

9. The UVM-based on-chip network switch verification method according to claim 1, characterized in that, After receiving and comparing the verification results of the reference model with the actual output results of the DUT to obtain the comparison verification results and realize the verification of the transaction to be tested, the process also includes: Obtain the single verification results of multiple transactions to be tested, including random test transactions and targeted test transactions; The comparison verification results and coverage collection results in the single verification results of multiple transactions to be tested are comprehensively analyzed to obtain comprehensive analysis results, which include verification pass rate, functional coverage compliance rate and code coverage compliance rate. If the comprehensive analysis results indicate that the pass rate is not up to standard or the coverage does not reach the preset target, then add targeted test cases and continue to execute the verification process until the pass rate meets the standard and the coverage reaches the preset target. If the comprehensive analysis results show that the pass rate meets the standard and the coverage reaches the preset target, then the overall verification of the on-chip network switch is completed and a comprehensive verification report is generated.

10. A UVM-based on-chip network switch verification platform, characterized in that, The verification platform includes a Control Status Register (CSR) configuration agent component, an agent component, a monitor, a coverage collector, a reference model, and a scoreboard; the reference model has a built-in routing table mirroring module; the verification platform stores a computer program, and the verification platform calls and runs the computer program to perform the method as described in any one of claims 1 to 9.

Images