Object-oriented on-chip network verification environment construction method and verification system

Abstract

The application provides an object-oriented network-on-chip verification environment construction method and a verification system. The application adopts class template parameterization configuration, uniformly manages the types and quantities of Agents and Scoreboards through template parameters, and realizes rapid adaptation of the verification environment. The application adopts a dynamic data flow comparison path technology, solves the multi-channel data confusion problem through the corresponding connection of Agents and FIFOs, and improves the comparison accuracy. The application also adopts a reinforcement learning dynamic scene generation technology to replace artificial pre-defined scenes, optimizes scenes in real time based on coverage and data flow state, and improves the dynamic scene coverage. The application applies the object-oriented class template mechanism and the reinforcement learning technology to the construction of the NoC verification environment, realizes the parameterization and intelligent construction of the verification environment.

Description

Technical Field

[0001] This application relates to the field of chip verification technology, and in particular to an object-oriented method for constructing an on-chip network verification environment and an on-chip network verification system. Background Technology

[0002] With the increasing integration of semiconductor chips, Network on Chip (NoC) has become the core communication infrastructure for multi-core chips, and its topology (such as Mesh, Torus) and data flow patterns (such as unicast, multicast) are becoming increasingly complex. Existing NoC verification environments based on the UVM (Universal Verification Methodology) framework have the following technical shortcomings:

[0003] Poor configuration flexibility: The type and quantity of core verification components such as Agent and Scoreboard need to be hard-coded and defined. When adapting to different NoC scenarios, the underlying code needs to be refactored, resulting in low reusability.

[0004] Incomplete verification scenario coverage: Traditional verification relies on manually predefined scenarios, which are difficult to cover complex scenarios such as dynamic data streams and channel conflicts, resulting in insufficient verification coverage.

[0005] Weak verification collaboration: Simulation verification and formal verification are independent of each other, dynamic scenarios and boundary scenarios cannot be covered collaboratively, and key issues such as deadlock are easily missed.

[0006] Passive conflict handling: There is a lack of real-time detection and adaptive adjustment mechanisms for abnormal scenarios such as NoC channel conflicts and congestion, resulting in low verification efficiency.

[0007] Therefore, there is an urgent need for a parameterized, scalable, and highly collaborative NoC verification environment construction solution to address the pain points of existing technologies. Summary of the Invention

[0008] This application provides an object-oriented method for constructing an on-chip network verification environment and an on-chip network verification system to solve the technical problems of poor configuration flexibility and incomplete coverage of verification scenarios in NoC verification environments.

[0009] Based on one aspect of the embodiments of this application, this application provides an object-oriented on-chip network verification environment construction method, the method comprising:

[0010] In the verification environment of the Network-on-Chip (NoC), class template parameters are defined at the top level. The class template parameters include at least: input and output agent types, number of input and output agents, scoreboard type, number of data flow channels, and simulation verification scenario parameters.

[0011] Based on the class template parameters, the corresponding number of input and output agent instances are automatically instantiated, and a unique channel identifier is bound to each agent instance;

[0012] Based on the class template parameters, a scoreboard instance is instantiated. The scoreboard instance contains parameterized input and output FIFOs, wherein the number of output FIFOs corresponds one-to-one with the number of output agent instances.

[0013] Establish connections between the input agent instance and the input FIFO in the scoreboard instance, and between the output agent instance and the output FIFO in the scoreboard instance, forming a complete data flow comparison path;

[0014] A reinforcement learning model is embedded in the verification environment. The reinforcement learning model collects verification coverage data and data stream operation status in real time to generate new verification scenario parameters.

[0015] Based on the new verification scenario parameters, the number of agent instances, channel management mode, and configuration parameters of scoreboard instances are dynamically adjusted to execute the new verification.

[0016] Furthermore, the method also includes a step of coordinating simulation verification and formal verification:

[0017] (a) Construct a parameterized fusion architecture for simulation verification and formal verification, set a unified parameter interface, synchronize the simulation verification scenario parameters to the formal verification tool through the unified parameter interface, and import the boundary scenario verification results output by the formal verification tool into the scoreboard instance;

[0018] (b) Based on the unified parameter interface, control the simulation verification module to cover dynamic verification scenarios and the formal verification tool to cover boundary verification scenarios, forming a verification closed loop in which simulation verification and formal verification work together.

[0019] Furthermore, the method also includes a real-time channel conflict resolution step:

[0020] (a) Deploy a channel conflict detection module in the encapsulation layer of the verification environment;

[0021] (b) The node traffic and link load of the NoC topology are monitored in real time through the channel conflict detection module, and potential conflict points are predicted by graph theory shortest path algorithm;

[0022] (c) Based on the prediction results of the potential conflict points, trigger the reconfiguration of the agent instance and generate a conflict scenario verification test case; the reconfiguration of the agent instance includes adjusting the data sending rate and switching the data stream transmission path.

[0023] Based on another aspect of the embodiments of this application, this application also provides a non-transitory computer-readable storage medium storing a computer program, which, when executed by a processor, implements the aforementioned object-oriented on-chip network verification environment construction method.

[0024] Based on another aspect of the embodiments of this application, this application also provides an on-chip network verification system. The verification system uses the aforementioned object-oriented on-chip network verification environment construction method to construct the verification environment. The verification system includes a hardware simulation platform and a verification toolchain.

[0025] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:

[0026] This application employs template-based parameterized configuration, uniformly managing the types and quantities of Agents and Scoreboards through template parameters to achieve rapid adaptation of the verification environment. It utilizes dynamic data flow comparison path technology, resolving multi-channel data confusion issues through the correspondence between Agents and FIFOs, thus improving comparison accuracy. Furthermore, this application employs reinforcement learning-based dynamic scene generation technology to replace manually predefined scenes, optimizing scenes in real-time based on coverage and data flow status, thereby improving dynamic scene coverage. This application integrates object-oriented template mechanisms with reinforcement learning technology for NoC verification environment construction, achieving parameterized and intelligent construction of the verification environment.

[0027] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0028] Figure 1 A flowchart illustrating an object-oriented on-chip network verification environment construction method provided in an embodiment of this application;

[0029] Figure 2 A schematic diagram of a parameterized fusion architecture for simulation verification and formal verification provided in an embodiment of this application;

[0030] Figure 3 This is a schematic diagram illustrating the discrete management mode supported by the Scoreboard instance in one embodiment of this application. Detailed Implementation

[0031] The exemplary embodiments will now be described in detail. When the description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification; they are merely exemplary embodiments of apparatuses and methods consistent with some aspects of this specification.

[0032] This application provides an object-oriented NoC verification environment construction scheme. The core is to realize the parameterized configuration of verification components through the class template parameter mechanism, combine reinforcement learning to dynamically generate verification scenarios, and simultaneously build a collaborative architecture for simulation and formal verification. It is equipped with a real-time channel conflict resolution mechanism to achieve rapid construction, flexible adaptation and efficient verification of the verification environment.

[0033] The technical solution of this application will be described in detail below with reference to the accompanying drawings. The following embodiments all take the NoC verification scenario of 4×4 Mesh topology (adapting to multi-source and multi-target node communication) as an example, and are implemented using SystemVerilog language + UVM framework. The hardware simulation platform is Synopsys VCS simulator, and the formal verification tool is Cadence Conformal.

[0034] Figure 1 This is a flowchart illustrating a method for constructing an object-oriented on-chip network verification environment according to an embodiment of this application. The method includes:

[0035] S11. Define class template parameters at the top level of the on-chip network verification environment. The class template parameters include at least: input and output agent types, number of input and output agents, scoreboard type, number of data flow channels, and simulation verification scenario parameters.

[0036] In a preferred embodiment, the class template parameters may further include: NoC topology type parameters, data flow mode type parameters, verification coverage model type, and other parameters. By extending the class template parameters, multi-dimensional scenario adaptation can be achieved without modifying the underlying code. Different topologies such as Mesh / Torus and different data flow modes such as unicast / multicast can be adapted simply by configuring the parameters, thus improving the flexibility of scenario adaptation.

[0037] S12. Based on the class template parameters, automatically instantiate the corresponding number of input and output Agent instances, and bind a unique channel identifier to each Agent instance;

[0038] In one embodiment of this application, both the input and output Agent instances inherit from the generic Agent base class in the UVM framework. The generic Agent base class includes a generic Driver sub-component and a generic Monitor sub-component, which are used to implement data stream timing and channel identifier recording functions. In NoC verification scenarios, the object-oriented inheritance mechanism achieves a balance between reusing general functions and extending specific functions, overcoming the limitations of existing Agent component functional coupling, and significantly improving development efficiency and component reusability.

[0039] S13. Based on the class template parameters, instantiate a Scoreboard instance. The Scoreboard instance contains parameterized input and output FIFOs, wherein the number of output FIFOs corresponds one-to-one with the number of output Agent instances.

[0040] S14. Establish the connection between the input Agent instance and the input FIFO in the Scoreboard instance, and the connection between the output Agent instance and the output FIFO in the Scoreboard instance, forming a complete data flow comparison path;

[0041] S15. Embed a reinforcement learning model in the verification environment, and use the reinforcement learning model to collect verification coverage data and data stream operation status in real time to generate new verification scenario parameters.

[0042] In one embodiment of this application, the reinforcement learning model employs either a Deep Q-Network (DQN) algorithm or a Proximal Policy Optimization (PPO) algorithm, supporting the selection and switching between the two algorithms to adapt to different validation scenarios. The DQN algorithm is suitable for simple scenarios and generates parameters quickly; the PPO algorithm is suitable for complex scenarios and improves training stability. Through precise matching of the algorithm and the scenario, the pain point of unstable algorithm training in complex scenarios can be solved.

[0043] S16. Based on the new verification scenario parameters, dynamically adjust the number of Agent instances, channel management mode, and configuration parameters of the Scoreboard instance, and execute the new verification.

[0044] For a 4×4 Mesh topology NoC (4 source nodes, 4 target nodes), the specific implementation example of the NoC verification environment construction method provided in this example is as follows:

[0045] (1) Define class template parameters: Define class template parameters at the top level of the verification environment (subclass of uvm_env, named noc_env). The specific parameters and their value examples are as follows:

[0046] / / Example of template parameter definition for the top-level class of the verification environment

[0047] class noc_env #(

[0048] / / Input / output Agent type (custom subclass, inheriting from the generic Agent base class)

[0049] type IN_AGENT_TYPE= noc_in_agent, / / Input Agent type

[0050] type OUT_AGENT_TYPE = noc_out_agent, / / Output Agent type

[0051] / / Input / Output Number of Agents

[0052] intIN_AGENT_NUM = 4, / / Input the number of Agents (corresponding to 4 source nodes)

[0053] intOUT_AGENT_NUM = 4, / / Output the number of Agents (corresponding to 4 target nodes)

[0054] / / Scoreboard type (custom subclass)

[0055] type SCOREBOARD_TYPE = noc_scoreboard, / / Scoreboard type

[0056] / / Number of data stream channels (same as the number of output Agents)

[0057] intCHANNEL_NUM = 4, / / Number of data stream channels

[0058] / / Simulation verification of scenario parameters (initial values)

[0059] intSIM_SCENE_PARAM = 0 / / 0 - unicast dynamic scenario, 1 - multicast dynamic scenario

[0060] ) extends uvm_env;

[0061] `uvm_component_utils(noc_env)

[0062] / / Component declaration (instantiation in subsequent steps)

[0063] IN_AGENT_TYPE in_agents[IN_AGENT_NUM]; / / Input array of Agent instances

[0064] OUT_AGENT_TYPE out_agents[OUT_AGENT_NUM]; / / Outputs an array of Agent instances.

[0065] SCOREBOARD_TYPE sb; / / Scoreboard instance

[0066] endclass

[0067] (2) Automatically instantiate Agent instances and bind channel identifiers: In the build phase of noc_env, based on the above parameters, automatically instantiate 4 input Agent instances and 4 output Agent instances, and bind a unique channel identifier (0-3) to each instance. The code implementation example is as follows:

[0068] virtual function void build_phase(uvm_phase phase);

[0069] super.build_phase(phase);

[0070] / / Instantiate the input Agent instance and bind the channel identifier

[0071] foreach(in_agents[i]) begin

[0072] in_agents[i] = IN_AGENT_TYPE::type_id::create($sformatf("in_agent_% 0d", i), this);

[0073] in_agents[i].channel_id = i; / / Bind a unique channel identifier (0-3)

[0074] end

[0075] / / Instantiate the output Agent instance and bind the channel identifier

[0076] foreach(out_agents[i]) begin

[0077] out_agents[i] = OUT_AGENT_TYPE::type_id::create($sformatf("out_ agent_%0d", i), this);

[0078] out_agents[i].channel_id = i; / / Bind a unique channel identifier (0-3)

[0079] end

[0080] endfunction

[0081] (3) Instantiate a Scoreboard instance (parameterized FIFO configuration): Also in build_phase, instantiate a Scoreboard instance, configure the number of input FIFOs to 1 (initial unified management mode) and the number of output FIFOs to 4 (corresponding one-to-one with the number of output Agents), the code implementation is as follows:

[0082] / / Scoreboard class template parameter definition (supports parameterization of FIFO quantity)

[0083] class noc_scoreboard #(

[0084] int IN_FIFO_NUM = 1, / / Input the number of FIFOs

[0085] int OUT_FIFO_NUM = 4 / / Number of output FIFOs (same as the number of output Agents)

[0086] ) extends uvm_scoreboard;

[0087] `uvm_component_utils(noc_scoreboard)

[0088] / / Parameterized FIFO declaration

[0089] uvm_tlm_analysis_fifo#(noc_data) in_fifos[IN_FIFO_NUM]; / / Input FIFO (buffered) (Expected data)

[0090] uvm_tlm_analysis_fifo#(noc_data) out_fifos[OUT_FIFO_NUM]; / / Output FIFO (Cache actual data)

[0091] / / FIFO instantiation

[0092] virtual function void build_phase(uvm_phase phase);

[0093] super.build_phase(phase);

[0094] foreach(in_fifos[i]) in_fifos[i]= new($sformatf("in_fifo_%0d", i), this);

[0095] foreach(out_fifos[i]) out_fifos[i]= new($sformatf("out_fifo_%0d", i), this);

[0096] endfunction

[0097] endclass

[0098] / / Instantiate Scoreboard in the top-level environment

[0099] virtual function void build_phase(uvm_phase phase);

[0100] super.build_phase(phase);

[0101] sb = SCOREBOARD_TYPE#(.IN_FIFO_NUM(1), .OUT_FIFO_NUM(OUT_AGENT_ NUM))::type_id::create("sb", this);

[0102] endfunction

[0103] (4) Establishing a data flow comparison path: In the connect_phase of noc_env, the connection between the Agent and the Scoreboard FIFO is established through the analysis_port of UVM, forming a complete path of "Input Agent → Input FIFO → Scoreboard comparison → Output FIFO → Output Agent". The code implementation example is as follows:

[0104] virtual function void connect_phase(uvm_phase phase);

[0105] super.connect_phase(phase);

[0106] / / Enter Agent → Enter FIFO (All entered Agents share 1 entered FIFO)

[0107] foreach(in_agents[i]) begin

[0108] in_agents[i].monitor.ap.connect(sb.in_fifos[0].analysis_export);

[0109] end

[0110] / / Output Agent → Output FIFO (each output Agent corresponds to one output FIFO)

[0111] foreach(out_agents[i]) begin

[0112] out_agents[i].monitor.ap.connect(sb.out_fifos[i].analysis_export);

[0113] end

[0114] endfunction

[0115] (5) Embedding reinforcement learning model and collecting data to generate parameters: Embed reinforcement learning model (initially using DQN algorithm) in the verification environment. The model collects verification coverage data (functional coverage, code coverage) and data flow running status (node ​​traffic, link load) in real time through UVM's config_db (configuration database) to generate new simulation verification scenario parameters (such as switching to multicast dynamic scenario, SIM_SCENE_PARAM=1). The code implementation example is as follows:

[0116] / / Reinforcement learning model class (DQN algorithm)

[0117] class rl_model #(

[0118] int IN_AGENT_NUM = 4,

[0119] int OUT_AGENT_NUM = 4

[0120] ) extends uvm_component;

[0121] `uvm_component_utils(rl_model)

[0122] / / Data acquisition interface

[0123] uvm_analysis_imp#(coverage_data, rl_model) coverage_imp; / / Coverage count According to the collection

[0124] uvm_analysis_imp#(data_status, rl_model) status_imp; / / Data stream status acquisition

[0125] / / Output parameters for the new scene

[0126] int new_sim_scene_param;

[0127] / / Real-time data collection

[0128] virtual function void write_coverage_data(coverage_data cov_data);

[0129] / / Collect coverage data (e.g., whether the functional coverage reaches 80%).

[0130] endfunction

[0131] virtual function void write_data_status(data_status stat_data);

[0132] / / Collect data stream status (e.g., whether the traffic of node 0 exceeds the threshold).

[0133] endfunction

[0134] / / Generate new scene parameters (core logic of DQN algorithm)

[0135] virtual task run_phase(uvm_phase phase);

[0136] forever begin

[0137] #100ns; / / Update parameters every 100ns

[0138] / / DQN algorithm: Generates new scene parameters with coverage improvement as the reward.

[0139] if(coverage_data.func_cov<80) begin

[0140] new_sim_scene_param = 1; / / Switch to multicast scene to improve coverage.

[0141] end else begin

[0142] new_sim_scene_param = 0; / / Maintain unicast scene

[0143] end

[0144] / / Write the new parameters to the configuration database

[0145] uvm_config_db#(int)::set(null, "*", "new_sim_scene_param", new_sim_ scene_param);

[0146] end

[0147] endtask

[0148] endclass

[0149] / / Embedding reinforcement learning models in the top-level environment

[0150] virtual function void build_phase(uvm_phase phase);

[0151] super.build_phase(phase);

[0152] rl_model#(.IN_AGENT_NUM(IN_AGENT_NUM), .OUT_AGENT_NUM(OUT_AGENT_NUM)) rl_inst;

[0153] rl_inst = rl_model::type_id::create("rl_inst", this);

[0154] endfunction

[0155] (6) Dynamically adjust parameters and execute new verification: The verification environment reads the new scenario parameters from config_db, dynamically adjusts the number of Agents (e.g., add 2 input Agents, IN_AGENT_NUM=6), channel management mode (switch to discrete management), Scoreboard FIFO configuration (number of input FIFOs=6), and restarts the verification process. The code implementation example is as follows:

[0156] virtual task run_phase(uvm_phase phase);

[0157] super.run_phase(phase);

[0158] int new_sim_scene_param;

[0159] forever begin

[0160] / / Read new scene parameters

[0161] uvm_config_db#(int)::get(null, this, "new_sim_scene_param", new_sim_ scene_param);

[0162] / / Dynamically adjust parameters

[0163] if(new_sim_scene_param == 1) begin

[0164] / / Adjust the number of Agents: Increase the number of Agents from 4 to 6

[0165] IN_AGENT_NUM = 6;

[0166] / / Adjust channel management mode: Discrete management (each channel corresponds to an independent input FIFO)

[0167] sb.IN_FIFO_NUM = 6;

[0168] / / Reconfigure Scoreboard FIFO

[0169] sb.reconfig_fifo(6, 4);

[0170] end

[0171] / / Perform new verification

[0172] run_new_simulation(phase);

[0173] end

[0174] endtask

[0175] As can be seen from the above embodiments, the object-oriented on-chip network verification environment construction method provided in this application adopts a template-based parameterized configuration technology, which breaks through the limitations of traditional hard-coded configuration. It manages the type and quantity of Agents and Scoreboards uniformly through template parameters, enabling rapid adaptation of the verification environment (e.g., switching to a 2×2 Mesh topology only requires modifying the Agent quantity parameter to 2), significantly improving component reusability. This application also employs dynamic data flow comparison path technology, solving the problem of multi-channel data confusion through a one-to-one correspondence between Agents and FIFOs, greatly improving comparison accuracy. Furthermore, this application uses reinforcement learning dynamic scene generation technology, which can replace manually predefined scenes and optimize scenes in real time based on coverage and data flow status, improving dynamic scene coverage. This embodiment integrates the object-oriented template mechanism with reinforcement learning technology for NoC verification environment construction, overcoming the technical problems of cumbersome configuration, incomplete scene coverage, and low reusability in traditional technologies. It achieves parameterized and intelligent construction of the verification environment, significantly improving the verification efficiency of NoC chips and covering more comprehensive scenarios.

[0176] Figure 2 This is a schematic diagram of a parameterized fusion architecture for simulation verification and formal verification provided in an embodiment of this application. In this embodiment, a parameterized fusion architecture for collaborative simulation verification and formal verification is adopted in the object-oriented on-chip network verification environment construction method, including the following steps:

[0177] S21. Construct a parameterized fusion architecture for simulation verification and formal verification, set a unified parameter interface (201), synchronize the simulation verification scenario parameters to the formal verification tool (203) through the unified parameter interface, and import the boundary scenario verification results output by the formal verification tool into the Scoreboard instance.

[0178] S22. Based on the unified parameter interface (201), control the simulation verification module (202) to cover the dynamic verification scenario and the formal verification tool to cover the boundary verification scenario, forming a verification closed loop in which simulation verification and formal verification work together.

[0179] This embodiment adds a collaborative function between simulation and formal verification based on the verification environment of the previous embodiments, and the specific implementation is as follows:

[0180] (a) Construct a parameterized fusion architecture and set up a unified parameter interface:

[0181] Constructing a fusion architecture: A parameterized fusion architecture module (200) (named fusion_arch) is added to the top layer of the verification environment. This module connects the simulation verification module (202) (including input / output agents, scoreboards, etc.), formal verification tools (203) (such as Cadence Conformal) and the design under test (204) (such as NoC chips). It supports configuring collaborative strategies (such as synchronization period and data transmission format) through class template parameters.

[0182] Setting up a unified parameter interface: The SystemVerilog DPI interface is adopted as the unified parameter interface (201). Interface functions are defined (synchronizing scene parameters, importing boundary results). The code implementation example is as follows:

[0183] systemverilog

[0184] / / Unified Parameter Interface (SystemVerilog DPI)

[0185] module dpi_interface;

[0186] / / Import DPI function (obtain boundary results from formal verification tools)

[0187] import "DPI-C" function void get_formal_result(input int* formal_ result, output int result_len);

[0188] / / DPI export function (synchronize simulation scene parameters to formal verification tools)

[0189] export "DPI-C" function set_sim_scene_param;

[0190] / / Synchronize simulation scene parameters to formal verification tool

[0191] function void set_sim_scene_param(int sim_scene_param);

[0192] / / The generated new_sim_scene_param is synchronized to the formal verification tool

[0193] uvm_config_db#(int)::get(null, "*", "new_sim_scene_param", sim_scene_ param);

[0194] / / DPI communication: Sending parameters to the formal verification tool

[0195] endfunction

[0196] / / Import formal validation boundary results into Scoreboard

[0197] function void import_formal_result;

[0198] int formal_result

[100] ; / / Boundary results (such as deadlock detection results)

[0199] int result_len;

[0200] get_formal_result(formal_result, result_len);

[0201] / / Write boundary results to Scoreboard

[0202] uvm_config_db#(int[])::set(null, "*", "formal_result", formal_ result);

[0203] endfunction

[0204] endmodule

[0205] / / Calling the DPI interface in the converged architecture module

[0206] class fusion_arch extends uvm_component;

[0207] `uvm_component_utils(fusion_arch)

[0208] virtual task run_phase(uvm_phase phase);

[0209] forever begin

[0210] #200ns;

[0211] set_sim_scene_param(0); / / Synchronize scene parameters

[0212] import_formal_result; / / Import boundary results

[0213] end

[0214] endtask

[0215] endclass

[0216] (b) Control collaborative verification and form a closed loop:

[0217] Scenario division of labor: The simulation verification module (202) is controlled by the unified parameter interface (201) to cover dynamic scenarios (such as burst data flow, path switching, unicast / multicast, etc.), and the formal verification tool (203) covers boundary scenarios (such as deadlock, extreme load, node failure).

[0218] Result Fusion: The scoreboard simultaneously receives dynamic data from simulation verification (from the output FIFO) and boundary results from formal verification (from the DPI interface), performs comprehensive comparison, and forms a collaborative closed loop of "scenario synchronization → division of labor verification → result fusion → parameter optimization". A code implementation example is as follows:

[0219] systemverilog

[0220] / / Added collaborative result comparison logic to Scoreboard

[0221] virtual task run_phase(uvm_phase phase);

[0222] noc_data exp_data, act_data;

[0223] int formal_result

[100] ;

[0224] forever begin

[0225] / / Read the form to verify the boundary results

[0226] uvm_config_db#(int[])::get(null, this, "formal_result", formal_ result);

[0227] / / Simulation data comparison (dynamic scenario)

[0228] sb.in_fifos[0].get(exp_data);

[0229] sb.out_fifos[exp_data.channel_id].get(act_data);

[0230] compare_data(exp_data, act_data);

[0231] / / Boundary result comparison (formal verification)

[0232] check_formal_result(formal_result);

[0233] / / Comprehensive judgment to verify correctness

[0234] if(compare_pass&&formal_pass) begin

[0235] `uvm_info("VERIFY_PASS", "Dynamic scene + boundary scene verification passed", UVM_MEDIUM)`

[0236] end

[0237] end

[0238] endtask

[0239] This embodiment is the first to apply a parameterized architecture to the collaboration of NoC simulation and formal verification, overcoming the industry's technical bias that the two types of verification cannot be synchronized and that boundary scenarios are easily missed. In addition, it can significantly improve the verification coverage and significantly improve the accuracy of key issue detection.

[0240] Figure 3 This is a schematic diagram illustrating the discrete management mode supported by the Scoreboard instance in one embodiment of this application.

[0241] The Scoreboard instance in this application supports two channel management modes: unified management mode and discrete management mode. In unified management mode, data from all data stream channels are aggregated in the same input FIFO. In discrete management mode, each data stream channel corresponds to an independent input FIFO.

[0242] Figure 3 The example demonstrates the component connectivity and data flow in a discrete channel management mode within a Mesh topology NoC verification environment. In this mode, each data stream channel corresponds to an independent input FIFO, enabling independent caching and accurate comparison of multi-channel data, suitable for complex data stream scenarios such as multicast and out-of-order transmission.

[0243] The input agent (NOC_IN_AGENT) section includes multiple input agent instances (managed through an AGENT array, where IN_AGENT_NUM is the number of input agent instances). The input agent instances are used to simulate NoC source nodes sending data, and each agent is bound to a unique channel identifier.

[0244] The output agent (NOC_OUT_AGENT) section includes multiple output agent instances (managed through an AGENT array, where OUT_AGENT_NUM is the number of output agent instances). The output agents are used to simulate the NoC target node receiving data, and each agent corresponds to a data stream channel.

[0245] The design under test (DUT) is a NoC chip under test, which contains multiple parallel data flow paths (DATA_FLOW [0]~DATA_FLOW [CHANNEL_PROC_NUM], where CHANNEL_PROC_NUM is the number of channels).

[0246] The scoreboard section includes multiple scoreboard instances and contains multiple sets of input / output FIFOs and channel processing units (CHANNEL_PROC[0]~ CHANNEL_PROC[CHANNEL_PROC_NUM]) to verify the core components.

[0247] v_fifo[0~CHANNEL_PROC_NUM] is the input FIFO / output FIFO, which is a first-in-first-out queue for buffering data streams. In discrete mode, the number of input FIFOs is the same as the number of channels.

[0248] CHANNEL_PROC[CHANNEL_PROC_NUM] is a channel processing unit used to independently compare the expected data (input FIFO) with the actual data (output FIFO) of the corresponding channel.

[0249] The discrete channel management model has the following characteristics:

[0250] (1) Independence of data flow channels:

[0251] In the discrete management mode, each data stream channel (DATA_FLOW [0]~DATA_FLOW [CHANNEL_PROC_NUM]) corresponds to a unique input FIFO, output FIFO and channel processing unit.

[0252] For example, the input agent's AGENT[0] can correspond to data stream channel 0. The data sent enters the DATA_FLOW[0] of the DUT (Design Under Test) through v_fifo[0] between the DUT and the DUT. The data stream output by the NoC chip under test is output to the output agent. The AGENT[0] in the output agent outputs the data stream to the channel processing unit CHANNEL_PROC[0] through v_fifo[0] between the output agent and the scoring board. The scoring board independently completes the comparison by comparing the output result of the reference model with the number of v_fifo[0] buffers corresponding to the output AGENT[0].

[0253] (2) Independent configuration of input FIFO

[0254] In the discrete management mode, the number of FIFOs in the Scoreboard is exactly the same as the number of data stream channels (N+1), and each input FIFO only caches the expected data for the corresponding channel. For example, the expected data of channel 1 sent by AGENT[1] is only written to v_fifo[1] (input FIFO) and will not be aggregated with data from other channels. This design avoids data confusion in multiple channels and ensures the accuracy of data comparison in complex scenarios (such as multicast concurrent transmission).

[0255] (3) Parallel operation of channel processing units

[0256] Each CHANNEL_PROC is only responsible for the data comparison of its corresponding channel, and each unit works in parallel: CHANNEL_PROC[0] only reads the expected data and actual data of v_fifo[0] to complete the comparison of channel 0. When a channel conflict is detected, it is only necessary to trigger the reconfiguration of the corresponding Agent (such as adjusting the sending rate of AGENT[0]), without affecting the verification process of other channels, thus improving the verification efficiency.

[0257] This application, through a flexible channel management mode, can adapt to complex scenarios, perfectly adapting to complex data stream scenarios such as multicast and out-of-order transmission, avoiding the data confusion problem of aggregated data under a unified management mode, and improving the accuracy of data comparison. Verification failures in a single channel (such as data errors) only affect the processing unit of the corresponding channel and do not propagate to other channels, thus improving the efficiency of problem localization. Furthermore, the parallel operation of multiple channel processing units also increases verification throughput, making it particularly suitable for high-concurrency data stream verification in large-scale NoC environments.

[0258] The object-oriented on-chip network verification environment construction method provided in one embodiment of this application also includes a real-time channel conflict resolution step. This embodiment adds a real-time channel conflict resolution function on the basis of the aforementioned verification environment, targeting link conflict scenarios in a 4×4 Mesh topology NoC (such as overlapping link conflicts between node 2→node 5 and node 3→node 4). A specific implementation example is as follows:

[0259] (a) Deploy a channel conflict detection module in the encapsulation layer of the verification environment;

[0260] A channel conflict detection module (channel_conflict_detector) is deployed in the verification environment wrapper layer (a subclass of uvm_env called noc_env_wrapper). This module collects node traffic and link load data of the NoC topology in real time through the UVM monitor interface. An example code implementation is shown below:

[0261] systemverilog

[0262] / / Channel collision detection module definition

[0263] class channel_conflict_detector extends uvm_component;

[0264] `uvm_component_utils(channel_conflict_detector)

[0265] / / Monitoring interface: Collects node traffic and link load

[0266] uvm_analysis_imp#(node_traffic, channel_conflict_detector) traffic_ imp

[0267] uvm_analysis_imp#(link_load, channel_conflict_detector) load_imp;

[0268] / / Internal data storage

[0269] node_traffic curr_traffic

[16] ; / / 4×4 Mesh with 16 nodes, storing the traffic of each node

[0270] link_load curr_load

[32] ; / / 32 links, storing the load (0-100%) of each link

[0271] / / Output of conflict prediction results

[0272] int potential_conflict_points

[10] ; / / Potential conflict points (link numbers)

[0273] int conflict_cnt; / / Number of potential conflict points

[0274] virtual function void build_phase(uvm_phase phase);

[0275] super.build_phase(phase);

[0276] traffic_imp = new("traffic_imp", this);

[0277] load_imp = new("load_imp", this);

[0278] endfunction

[0279] / / Real-time collection of node traffic

[0280] virtual function void write_node_traffic(node_traffic traf);

[0281] curr_traffic[traf.node_id] = traf;

[0282] `uvm_info("TRAFFIC_COLLECT", $sformatf("Node %d traffic: %d Mbps", traf.node_id, traf.rate), UVM_LOW)

[0283] endfunction

[0284] / / Real-time collection of link load

[0285] virtual function void write_link_load(link_load ld);

[0286] curr_load[ld.link_id] = ld;

[0287] `uvm_info("LOAD_COLLECT", $sformatf("Link %d load: %d%%", ld.link_id, ld.load), UVM_LOW)

[0288] endfunction

[0289] endclass

[0290] / / Deploy modules and connect interfaces in the encapsulation layer

[0291] class noc_env_wrapper extends uvm_env;

[0292] `uvm_component_utils(noc_env_wrapper)

[0293] noc_env env; / / Existing verification environment instance

[0294] channel_conflict_detector conflict_detector;

[0295] virtual function void build_phase(uvm_phase phase);

[0296] super.build_phase(phase);

[0297] env = noc_env::type_id::create("env", this);

[0298] conflict_detector = channel_conflict_detector::type_id::create(" conflict_detector", this);

[0299] endfunction

[0300] virtual function void connect_phase(uvm_phase phase);

[0301] super.connect_phase(phase);

[0302] / / Connect to the traffic / load monitoring interface (collect data from NoC monitor)

[0303] env.dut_monitor.traffic_ap.connect(conflict_detector.traffic_imp);

[0304] env.dut_monitor.load_ap.connect(conflict_detector.load_imp);

[0305] endfunction

[0306] endclass

[0307] (b) The node traffic and link load of the NoC topology are monitored in real time through the channel conflict detection module, and potential conflict points are predicted by graph theory shortest path algorithm;

[0308] The shortest path algorithm unit of the conflict detection module (e.g., using Dijkstra's shortest path algorithm based on graph theory) predicts potential conflict points (e.g., links with ≥80% link load or multiple overlapping paths) based on collected node traffic and link load data. The code implementation is as follows:

[0309] systemverilog

[0310] / / Added prediction logic to the channel collision detection module

[0311] class channel_conflict_detector extends uvm_component;

[0312] / / ... Existing code omitted...

[0313] / / Graph theory shortest path algorithm (Dijkstra's algorithm): Predicting potential conflict points

[0314] virtual function void predict_conflict_points();

[0315] int src_node, dst_node;

[0316] int shortest_path

[16] ; / / Shortest path node sequence

[0317] conflict_cnt = 0;

[0318] potential_conflict_points = '{default:-1};

[0319] / / Traverse all source and target nodes corresponding to the input Agent

[0320] foreach(env.in_agents[i]) begin

[0321] src_node = env.in_agents[i].src_node_id;

[0322] dst_node = env.out_agents[i].dst_node_id;

[0323] / / Use Dijkstra's algorithm to calculate the shortest path

[0324] dijkstra_algorithm(src_node, dst_node, shortest_path);

[0325] / / Analyze the link load corresponding to the path and predict the collision points.

[0326] for(int j=0; j<$size(shortest_path)-1; j++) begin

[0327] int link_id = get_link_id(shortest_path[j], shortest_path[j+1]); / / Get Link ID

[0328] if(curr_load[link_id].load ≥ 80) begin / / Load ≥ 80% is considered a potential conflict

[0329] potential_conflict_points[conflict_cnt] = link_id;

[0330] conflict_cnt++;

[0331] `uvm_warning("CONFLICT_PREDICT", $sformatf("Predicted link %d is a potential collision point, negative...")` Load: %d%%", link_id, curr_load[link_id].load))

[0332] end

[0333] end

[0334] end

[0335] endfunction

[0336] / / Implementation of Dijkstra's shortest path algorithm (core logic)

[0337] virtual function void dijkstra_algorithm(int src, int dst, output int path[]);

[0338] int dist

[16] ; / / Distance from the source node to each node

[0339] int visited

[16] ; / / Visited node marker

[0340] int prev_node

[16] ; / / Predecessor node

[0341] int min_dist, min_node;

[0342] / / Initialization

[0343] foreach(dist[i]) dist[i] = 1000; / / Set the initial distance to the maximum value

[0344] dist[src] = 0;

[0345] visited = '{default:0};

[0346] prev_node = '{default:-1};

[0347] / / Core Iteration Logic

[0348] for(int i=0; i<16; i++) begin

[0349] / / Find the node with the smallest distance among the unvisited nodes

[0350] min_dist = 1000;

[0351] min_node = -1;

[0352] foreach(dist[j]) begin

[0353] if (!visited[j]&&dist[j]) <min_dist) begin

[0354] min_dist = dist[j];

[0355] min_node = j;

[0356] end

[0357] end

[0358] if(min_node == -1) break; / / No reachable path

[0359] visited[min_node] = 1;

[0360] if(min_node == dst) break; / / Target node reached

[0361] / / Update the distance between adjacent nodes

[0362] foreach(env.noc_topo.adj_nodes[min_node][k]) begin

[0363] int adj_node = env.noc_topo.adj_nodes[min_node][k];

[0364] int link_load = curr_load[get_link_id(min_node, adj_node)].load;

[0365] int new_dist = dist[min_node] + link_load; / / Distance weight is the link load

[0366] if(new_dist <dist[adj_node]) begin

[0367] dist[adj_node] = new_dist;

[0368] prev_node[adj_node] = min_node;

[0369] end

[0370] end

[0371] end

[0372] / / Backtracking to generate the shortest path

[0373] int path_idx = 0;

[0374] int curr_node = dst;

[0375] while(curr_node != -1) begin

[0376] path[path_idx] = curr_node;

[0377] curr_node = prev_node[curr_node];

[0378] path_idx++;

[0379] end

[0380] / / Reverse the path (from source node to target node)

[0381] path = reverse(path[0:path_idx-1]);

[0382] endfunction

[0383] / / Helper function: Get the link ID based on two node IDs

[0384] virtual function int get_link_id(int node1, int node2);

[0385] return (node1 <node2) ? (node1*16 + node2) : (node2*16 + node1);

[0386] endfunction

[0387] / / Helper function: Reverse array

[0388] virtual function int[] reverse(int arr[]);

[0389] int rev_arr[$];

[0390] foreach(arr[i]) rev_arr.push_front(arr[i]);

[0391] return rev_arr;

[0392] endfunction

[0393] / / Periodic execution prediction

[0394] virtual task run_phase(uvm_phase phase);

[0395] forever begin

[0396] #50ns; / / Predict every 50ns

[0397] predict_conflict_points();

[0398] / / Write the prediction results to the configuration database for future reconfiguration.

[0399] uvm_config_db#(int[])::set(null,"*","potential_conflict_points", potential_conflict_points);

[0400] uvm_config_db#(int)::set(null, "*", "conflict_cnt", conflict_cnt);

[0401] end

[0402] endtask

[0403] endclass

[0404] (c) Based on the prediction results of the potential conflict points, trigger the reconfiguration of the Agent instance and generate a conflict scenario verification test case; the reconfiguration of the Agent instance includes adjusting the data sending rate and switching the data stream transmission path.

[0405] When a potential conflict point is predicted, based on the prediction result, the system triggers the reconfiguration of input / output agent instances (adjusting the sending rate and switching transmission paths), and automatically generates conflict scenario verification test cases (such as concurrent data transmission test cases on conflicting links). An example of the code implementation is as follows:

[0406] systemverilog

[0407] / / Add reconfiguration and test case generation logic at the top level of the verification environment

[0408] class noc_env extends uvm_env;

[0409] / / ... Existing code omitted...

[0410] virtual task run_phase(uvm_phase phase);

[0411] / / ... Existing dynamic adjustment logic omitted...

[0412] int potential_conflict_points

[10] ;

[0413] int conflict_cnt;

[0414] forever begin

[0415] / / Read conflict prediction results

[0416] uvm_config_db#(int[])::get(null, this, "potential_conflict_points", potential_conflict_points);

[0417] uvm_config_db#(int)::get(null, this, "conflict_cnt", conflict_cnt);

[0418] if(conflict_cnt>0) begin / / Potential conflict point exists

[0419] `uvm_info("CONFLICT_RESOLVE", $sformatf("%d potential conflict points were detected, triggering...")` Agent reconfiguration", conflict_cnt), UVM_MEDIUM)

[0420] / / Trigger Agent instance reconfiguration

[0421] resolve_agent_reconfig(potential_conflict_points);

[0422] / / Generate test cases for conflict scenarios

[0423] generate_conflict_testcase(potential_conflict_points);

[0424] end

[0425] #50ns;

[0426] end

[0427] endtask

[0428] / / Agent instance reconfiguration: Adjusting sending rate and switching transmission paths

[0429] virtual function void resolve_agent_reconfig(int conflict_links[]);

[0430] foreach(conflict_links[i]) begin

[0431] if(conflict_links[i] == -1) break;

[0432] / / Obtain the Agent instance corresponding to the conflict link (associate Agents based on the nodes at both ends of the link)

[0433] int agent_idx = get_agent_by_link(conflict_links[i]);

[0434] if(agent_idx != -1) begin

[0435] / / Adjust the data transmission rate (from 100Mbps to 50Mbps)

[0436] in_agents[agent_idx].drv.set_send_rate(50);

[0437] `uvm_info("AGENT_RECONFIG", $sformatf("Agent%d sending rate adjusted to 50Mbps", agent_idx), UVM_MEDIUM)

[0438] / / Switch the data stream transmission path (avoid conflicting links and recalculate the alternative path).

[0439] int new_path

[16] ;

[0440] int src_node = in_agents[agent_idx].src_node_id;

[0441] int dst_node = out_agents[agent_idx].dst_node_id;

[0442] conflict_detector.dijkstra_algorithm(src_node, dst_node, new_path, conflict_links[i]); / / Avoid the current conflicting link

[0443] in_agents[agent_idx].set_transfer_path(new_path);

[0444] `uvm_info("AGENT_RECONFIG", $sformatf("Agent%d transport path switched to: %p", agent_idx, new_path), UVM_MEDIUM)

[0445] end

[0446] end

[0447] endfunction

[0448] / / Generate test cases for conflict scenarios

[0449] virtual function void generate_conflict_testcase(int conflict_links []);

[0450] / / Create conflict scenario test cases (UVM test class)

[0451] conflict_testcase test = conflict_testcase::type_id::create(" conflict_testcase", this);

[0452] / / Configure test case parameters: conflicting link ID, concurrent transmission node pairs

[0453] test.conflict_links = conflict_links;

[0454] test.concurrency_pairs = get_concurrency_pairs(conflict_links); / / get Take the concurrent node pairs corresponding to the conflicting links

[0455] / / Start test case execution

[0456] test.run_test();

[0457] `uvm_info("TESTCASE_GENERATE", "Conflict scenario verification test cases have been generated and executed successfully", UVM_ MEDIUM)

[0458] endfunction

[0459] / / Helper function: Retrieve the associated Agent index based on the conflict link

[0460] virtual function int get_agent_by_link(int link_id);

[0461] / / ... Logic: Associate the source node through the link ID, and then associate it with the corresponding input Agent index...

[0462] return agent_idx;

[0463] endfunction

[0464] / / Helper function: Get the concurrent node pairs corresponding to the conflicting links

[0465] virtual function int[][]get_concurrency_pairs(int conflict_links[]);

[0466] / / ... Logic: Generate multiple sets of concurrent data transmission node pairs corresponding to conflicting links...

[0467] return concurrency_pairs;

[0468] endfunction

[0469] endclass

[0470] / / Conflict scenario verification test case class definition

[0471] class conflict_testcase extends uvm_test;

[0472] `uvm_component_utils(conflict_testcase)

[0473] int conflict_links

[10] ;

[0474] int concurrency_pairs[][2]; / / Concurrent transmission node pairs (source node, destination node)

[0475] virtual task run_phase(uvm_phase phase);

[0476] phase.raise_objection(this);

[0477] `uvm_info("CONFLICT_TEST", $sformatf("Execute conflict scenario verification, conflict link: %p, and...")` Send node pairs: %p, conflict_links, concurrency_pairs), UVM_MEDIUM)

[0478] / / Trigger concurrent data transmission to verify the conflict resolution effect

[0479] foreach(concurrency_pairs[i]) begin

[0480] env.in_agents[concurrency_pairs[i][0]].send_data();

[0481] env.out_agents[concurrency_pairs[i][1]].recv_data();

[0482] end

[0483] #1000ns;

[0484] phase.drop_objection(this);

[0485] endtask

[0486] endclass

[0487] This embodiment overcomes the limitation of traditional solutions lacking a dedicated conflict detection module by deploying a conflict detection module at the encapsulation layer. By independently deploying the detection function at the encapsulation layer without intruding on the core verification logic, it improves module reusability. This embodiment employs Dijkstra's shortest path algorithm combined with traffic / load monitoring to predict potential conflict points in advance, significantly improving the accuracy of conflict early warning. Furthermore, dynamic agent reconfiguration and automatic test case generation can replace manual intervention, enabling proactive adaptation before conflicts occur (adjusting sending rates, switching paths), while automatically generating conflict scenario test cases, greatly improving conflict resolution efficiency and conflict scenario verification coverage.

[0488] This embodiment combines the graph theory shortest path algorithm with the Agent dynamic reconfiguration mechanism and applies it to channel conflict resolution in NoC verification. It overcomes the industry technical pain points of passive conflict handling, manual intervention, and incomplete scenario coverage in traditional technologies. It realizes full-process automation of conflict "real-time monitoring - early prediction - proactive resolution - special verification", and the verification efficiency, conflict handling timeliness and scenario coverage are all significantly improved.

[0489] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A method for constructing an object-oriented on-chip network verification environment, characterized in that, include: In the verification environment of the Network-on-Chip (NoC), class template parameters are defined at the top level. The class template parameters include at least: input and output agent types, number of input and output agents, scoreboard type, number of data flow channels, and simulation verification scenario parameters. Based on the class template parameters, a corresponding number of input and output proxy instances are automatically instantiated, and a unique channel identifier is bound to each proxy instance; both the input and output proxy instances inherit from the general proxy base class; the general proxy base class contains a general driver subcomponent and a general monitor subcomponent, which are used to implement data stream timing and channel identifier recording functions; Based on the class template parameters, a scoreboard instance is instantiated. The scoreboard instance contains parameterized input and output FIFOs, wherein the number of output FIFOs corresponds one-to-one with the number of output proxy instances. Establish the connection relationship between the input agent instance and the input FIFO in the scoreboard instance, and the connection relationship between the output agent instance and the output FIFO in the scoreboard instance, forming a complete data flow comparison path; A reinforcement learning model is embedded in the verification environment. The reinforcement learning model collects verification coverage data and data stream operation status in real time to generate new verification scenario parameters. Based on the new verification scenario parameters, the number of proxy instances, channel management mode, and configuration parameters of the scoreboard instance are dynamically adjusted to execute the new verification.

2. The method according to claim 1, characterized in that, The method also includes a step of combining simulation verification and formal verification: (a) Construct a parameterized fusion architecture for simulation verification and formal verification, set a unified parameter interface, synchronize the simulation verification scenario parameters to the formal verification tool through the unified parameter interface, and import the boundary scenario verification results output by the formal verification tool into the scoreboard instance; (b) Based on the unified parameter interface, control the simulation verification module to cover dynamic verification scenarios and the formal verification tool to cover boundary verification scenarios, forming a verification closed loop in which simulation verification and formal verification work together.

3. The method according to claim 1, characterized in that, The class template parameters also include: NoC topology type parameters, data flow mode type parameters, and verification coverage model type parameters.

4. The method according to claim 1, characterized in that, The scoreboard instance supports two channel management modes: unified management mode and discrete management mode; in the unified management mode, data from all data stream channels are aggregated in the same input FIFO; In the discrete management mode, each data stream channel corresponds to an independent input FIFO.

5. The method according to claim 1, characterized in that, The reinforcement learning model employs either the Deep Q-Network (DQN) algorithm or the Proximal Policy Optimization (PPO) algorithm.

6. The method according to claim 2, characterized in that, The unified parameter interface is the SystemVerilog DPI interface, which is used to synchronize simulation verification scenario parameters and import deadlock proof results output by the formal verification tool.

7. The method according to claim 1, characterized in that, The method also includes a real-time channel conflict resolution step: (a) Deploy a channel conflict detection module in the encapsulation layer of the verification environment; (b) The node traffic and link load of the NoC topology are monitored in real time through the channel conflict detection module, and potential conflict points are predicted by graph theory shortest path algorithm; (c) Based on the prediction results of the potential conflict points, trigger the reconfiguration of the proxy instance and generate a conflict scenario verification test case; the reconfiguration of the proxy instance includes adjusting the data sending rate and switching the data stream transmission path.

8. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores a computer program, which, when executed by a processor, implements the object-oriented on-chip network verification environment construction method according to any one of claims 1 to 7.

9. An on-chip network verification system, characterized in that, The verification system constructs a verification environment using the method described in any one of claims 1 to 7, and the verification system includes a hardware simulation platform and a verification toolchain.

Images