A method, apparatus, device, and storage medium for path verification of on-chip networks.

Abstract

This application discloses a method, apparatus, device, and storage medium for path verification of on-chip networks, relating to the field of integrated circuit technology. The method includes: extracting the architecture information of the on-chip network to be verified; generating a corresponding verification environment based on the architecture information; selecting a target path and determining the target path parameters from the verification environment through a graphical user interface; running corresponding test cases based on the target path, target path parameters, and service scenarios, and obtaining the corresponding running results to complete the path verification of the on-chip network. It is evident that for different on-chip networks, only different architecture information files need to be filled in to generate corresponding verification environments, eliminating the need to generate separate verification environments for each on-chip network, reducing the repetitive workload and verification cycle for verification engineers; providing an intuitive graphical user interface allows verification engineers to arbitrarily select verification paths and path parameters, making operation convenient and enabling diverse path verification.

Description

Technical Field

[0001] This invention relates to the field of integrated circuit technology, and in particular to a method, apparatus, device, and storage medium for path verification of on-chip networks. Background Technology

[0002] With the development of integrated circuits, System-on-Chip (SoC) is increasingly moving towards large-scale, high-integration, high-complexity, high-performance, and low-power consumption. Furthermore, to efficiently process tasks, numerous IPs on the SoC demand high bandwidth, low latency, and other high-performance metrics for the data being processed. At this point, on-chip interconnects often become key to breakthroughs in overall SoC performance. Network-on-Chip (NoC), as a bus interconnect architecture, is used to connect multiple master and slave devices to achieve high-performance communication across the entire system. Its highly configurable, structured, and hierarchical organization borrows concepts from general-purpose networks, providing a highly efficient, flexible, and scalable solution for the system. On-chip network solutions are now the main development direction for SoC interconnects.

[0003] To meet the performance requirements of SoCs, on-chip networks (NICs) are increasingly being used. As mature, general-purpose IP (Intellectual Property Core), the NICs provided by various vendors are feature-rich and have undergone extensive verification. Therefore, the primary verification task for NICs in SoCs is to quickly achieve full-path verification. The current challenge in path verification for NICs in SoCs is the diversity of path types. A path refers to the route a host takes to access a slave device via a NoC (NoC). This diversity requires verification engineers to perform different tests based on the characteristics of each host-slave path. However, as the number of hosts and slaves and the types of protocols increase, ensuring the completeness of verification for each path becomes a problem that verification engineers must consider. Furthermore, if a host or its characteristics change, all related path verifications need to be modified. While changes are inevitable in the early stages of a project, this undoubtedly increases the repetitive workload for verification engineers. Therefore, the diversity of path types presents numerous problems and significant challenges for verification engineers. Facing numerous different NoCs, if a separate verification environment is built and test cases are developed for each one, the workload for verification engineers would be enormous.

[0004] In summary, finding commonalities in NoCs and making the verification process more universal, enabling the rapid verification of multiple NoCs, is a technical problem that needs to be solved in this field. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a method, apparatus, device, and storage medium for path verification of on-chip networks (NoCs), which can find the commonalities in NoCs, make the verification process universal, and quickly complete the verification of multiple NoCs. The specific solution is as follows:

[0006] In a first aspect, this application discloses a path verification method for on-chip networks, comprising:

[0007] Extract the architecture information of the on-chip network to be verified, and generate a corresponding verification environment based on the architecture information;

[0008] Select the target pathway and determine the target pathway parameters from the verification environment through a graphical user interface;

[0009] Based on the target path, the target path parameters, and the business scenario, run the corresponding test cases and obtain the corresponding running results to complete the path verification of the on-chip network.

[0010] Optionally, before extracting the architecture information of the on-chip network to be verified, the method further includes:

[0011] Fill in the information file of the network-on-chip to be verified, which includes the number, name, interface protocol, and path parameters of the interface units that interface with the host and the interface units that interface with the slave.

[0012] Optionally, the step of extracting the architecture information of the on-chip network to be verified and generating a corresponding verification environment based on the architecture information includes:

[0013] Extract the architecture information of the on-chip network to be verified in order to generate configuration information for configuring the verification environment;

[0014] A corresponding verification environment is generated based on the configuration information.

[0015] Optionally, generating the corresponding verification environment based on the architecture information includes:

[0016] The verification IP core is used to simulate the transmission behavior of the host and slave connected to the on-chip network to be verified, and corresponding paths are generated to create a corresponding verification environment; wherein, the path is used for the host and slave to transmit data through the on-chip network to be verified, the path protocol and the path parameters.

[0017] Optionally, the step of selecting the target path and determining the target path parameters from the verification environment through a graphical user interface includes:

[0018] Select a preset number of target paths from the verification environment through the graphical user interface, and specify the corresponding path parameters and / or default random path parameters for the target paths;

[0019] The path parameters and / or the default random path parameters are determined as the target path parameters.

[0020] Optionally, after running the corresponding test cases based on the target path, the target path parameters, and the business scenario, and obtaining the corresponding running results, the method further includes:

[0021] Based on the results, a simulation report is generated that includes waveform files, log files, test case regression results, and coverage files.

[0022] Optionally, after generating the simulation report containing waveform files, log files, test case regression results, and coverage files based on the execution results, the process further includes:

[0023] Determine whether the simulation results in the simulation report meet the preset simulation target. If not, execute the step of selecting the target path from the verification environment and determining the target path parameters through the graphical user interface.

[0024] Secondly, this application discloses a path verification device for an on-chip network, comprising:

[0025] The environment generation module is used to extract the architecture information of the on-chip network to be verified and generate a corresponding verification environment based on the architecture information.

[0026] The parameter determination module is used to select a target path from the verification environment and determine the target path parameters through a graphical user interface.

[0027] The path verification module is used to run corresponding test cases based on the target path, the target path parameters, and the business scenario, and obtain the corresponding running results to complete the path verification of the on-chip network.

[0028] Thirdly, this application discloses an electronic device, including:

[0029] Memory, used to store computer programs;

[0030] A processor is configured to execute the computer program to implement the steps of the aforementioned disclosed on-chip network path verification method.

[0031] Fourthly, this application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the steps of the aforementioned disclosed on-chip network path verification method.

[0032] Therefore, this application discloses a path verification method for on-chip networks, including: extracting the architecture information of the on-chip network to be verified, generating a corresponding verification environment based on the architecture information; selecting a target path from the verification environment and determining the target path parameters through a graphical user interface; running corresponding test cases based on the target path, the target path parameters, and the business scenario, and obtaining the corresponding running results to complete the path verification of the on-chip network. It is evident that for different on-chip networks, only different architecture information files need to be filled in to generate corresponding verification environments, eliminating the need to generate separate verification environments for each on-chip network, reducing the repetitive workload and verification cycle for verification engineers; providing an intuitive graphical user interface allows verification engineers to arbitrarily select verification paths and path parameters, making operation convenient and enabling diverse path verification. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, 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 embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0034] Figure 1 This is a flowchart of a path verification method for an on-chip network disclosed in this application;

[0035] Figure 2 This is an example diagram of a verification environment for a network-on-a-chip disclosed in this application;

[0036] Figure 3 This is a flowchart of a specific on-chip network path verification method disclosed in this application;

[0037] Figure 4 This is a flowchart of another specific on-chip network path verification method disclosed in this application;

[0038] Figure 5 This is a flowchart of the functional modules of a network-on-a-chip disclosed in this application;

[0039] Figure 6 This is a schematic diagram of the path verification device for an on-chip network disclosed in this application;

[0040] Figure 7 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0041] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0042] With the development of integrated circuits, System-on-a-Chip (SoC) is increasingly moving towards large-scale, high-integration, high-complexity, high-performance, and low-power consumption. Furthermore, to efficiently process tasks, numerous IPs on the SoC demand high bandwidth, low latency, and other high-performance metrics for the data being processed. At this point, on-chip interconnects often become key to breakthroughs in overall SoC performance. Network-on-a-Chip (NoC), as a bus interconnect architecture, is used to connect multiple masters and slaves to achieve high-performance communication across the entire system. Its highly configurable, structured, and hierarchical organization borrows concepts from general-purpose networks, providing a highly efficient, flexible, and scalable solution for the system. On-chip network solutions are now a major development direction for SoC interconnects.

[0043] To meet the performance requirements of SoCs, on-chip networks (NICs) are increasingly being used. As mature, general-purpose IPs, the NICs provided by various vendors are feature-rich and have undergone extensive verification. Therefore, the primary verification task for NICs in SoCs is to quickly achieve full-path verification. The current challenges in path verification for NICs in SoCs are: the diversity of path types, where a path refers to the path traversed by a host to access a slave device via a NoC. This diversity requires verification engineers to perform different tests based on the characteristics of each host-slave path. NoCs exhibit various variations, stemming from three factors: multiple different NoCs within a single SoC; different versions of a SoC leading to variations in NoCs; NoCs across different projects; and ensuring the completeness of verification for each path as the number of hosts and slaves and protocol types increase. Furthermore, if a host or its characteristics change, all related path verifications need to be modified. While changes are inevitable in the early stages of a project, this undoubtedly increases the repetitive workload for verification engineers. Therefore, the diversity of pathway types brings numerous problems and poses significant challenges to verification engineers. Faced with many different NoCs, if a separate verification environment must be built and test cases developed for each one, the workload for verification engineers would undoubtedly be enormous.

[0044] Therefore, this application discloses a path verification scheme for on-chip networks, which can find the universality in NoC and make the verification work universal. The ability to quickly complete the verification of multiple NoCs is a technical problem to be solved in this field.

[0045] Reference Figure 1 As shown, this embodiment of the invention discloses a path verification method for an on-chip network, including:

[0046] Step S11: Extract the architecture information of the on-chip network to be verified, and generate a corresponding verification environment based on the architecture information.

[0047] In this embodiment, the architecture information of the on-chip network to be verified is extracted to generate configuration information for configuring the verification environment; a corresponding verification environment is generated based on the configuration information. Specifically, the transmission behavior of the host and slave connected to the on-chip network to be verified is simulated using the verification IP core, and corresponding paths are generated to create a corresponding verification environment; wherein, the path is used for data transmission between the host and slave through the on-chip network to be verified, the path protocol, and the path parameters. The NoC verification environment is generated based on the extracted architecture information, and the following... Figure 2 This is an example diagram of a verification environment. The verification environment integrates a VIP (verification IP) to simulate the behavior of each Master and Slave, and also generates a base sequence for each path. Each path's base sequence randomly sends n transmissions within a random range of various parameters, based on the Master and Slave protocols and parameters of that path. These parameters can also be specified by the verification engineer to send specific transmissions.

[0048] In this embodiment, before extracting the architecture information of the on-chip network to be verified, the method further includes: filling in an information file of the on-chip network to be verified, containing the number, name, interface protocol, and path parameters of the interface units that interface with the host and the interface units that interface with the slave. It is understood that a SoC often consists of multiple subsystems, and correspondingly, multiple NoCs exist. The NoC is responsible for the connection and communication of various IPs on the SoC, and its functionality and performance are crucial to the entire SoC. The NoC IP launched by Arteris, a leading global interconnect IP company, is used as an example. Filling in the architecture information: The architecture engineer fills in the architecture information of the NoC, including all Initiator NIUs (NIUs defined by Arteris that interface with the host) and Target NIUs (NIUs defined by Arteris that interface with the slave) of the NoC:

[0049] 1) Number

[0050] 2) Name;

[0051] 3) Interface protocol and protocol parameters, such as the address width, data width, ID width, supported burst types, burst size range, and burst length range of AXI (on-chip bus);

[0052] 4) Address mapping relationship.

[0053] Due to the diversity of host protocols, NoC supports multiple protocols, such as AXI (ARM AMBA, Advanced Microcontroller Bus Architecture), AHB (Advanced High-Performance Bus), and APB (Aperture Bus). A single NoC can connect to multiple hosts, each using a different interface protocol. Each protocol involves various parameters, resulting in diverse access patterns. For example, a host using AHB as its interface protocol can only send address-aligned accesses, while a host using AXI can send address-unaligned accesses. A host using AXI as its interface protocol can send three types of bursts: FIXED, INCR, and WRAP. The burst length, address, and other parameters differ for each burst type. Even with the same protocol, different parameters result in different access patterns. For instance, two hosts using the same AXI interface protocol, host 1 with a 64-bit data width and host 2 with a 32-bit data width, will send different burst sizes. The diversity of slave protocols: Similarly, a NoC can connect to multiple slave devices, each of which can use different interface protocols. Each protocol involves a variety of parameters, resulting in a wide range of acceptable accesses. For example, a slave device using the AHB interface protocol can only receive address-aligned accesses, while a slave device using the AXI interface protocol can receive address-unaligned accesses. Then, based on the above architecture information, a corresponding verification environment is generated. This generated verification environment needs to support some protocols supported by the NoC, including but not limited to: AXI protocol, AHB protocol, NSP (Arteris NoC Socket) protocol, etc. In this way, by pre-filling the architecture information for all master-slave protocols and related parameters, only different architecture information files need to be filled in for different NoCs to generate corresponding verification environments. This eliminates the need to generate separate verification environments for each NoC, reducing the repetitive workload and verification cycle for verification engineers.

[0054] In this embodiment, since the verification environment is automatically generated based on the extracted architecture information, the update operation of the verification environment is also based on the extracted new architecture information. That is, when the entered architecture information changes, the verification environment will also be automatically updated based on the extracted changed architecture information.

[0055] Step S12: Select the target pathway and determine the target pathway parameters from the verification environment through the graphical user interface.

[0056] In this embodiment, the target path is selected by using the base sequence of each path in the verification environment displayed in the GUI (Graphical User Interface) interface, and the corresponding target path parameters and customized test cases are determined to verify the target path parameters.

[0057] Step S13: Based on the target path, the target path parameters, and the business scenario, run the corresponding test cases and obtain the corresponding running results to complete the path verification of the on-chip network.

[0058] In this embodiment, based on the determined target path, target path parameters, and business scenario, corresponding test cases are run. The business scenario is also a type of path, and the generated test cases can be of the type where the AHB Master supports issuing INCR type accesses. In the system, access may differ depending on the scenario. For example, a CPU with an AXI interface protocol acts as a master accessing three slave devices with the same AXI interface protocol. Slave 1 is a FIFO-based storage device, slave 2 is a device based on a single static storage unit, and slave 3 is also based on a contiguous static storage unit. Typically, the master will access slave 1 with a burst transmission of type FIXED and a data width equal to the FIFO data width. If the cache is disabled when the master accesses slave 2, it will typically access slave 2 with a burst transmission of type INCR and a size equal to the RAM data width. If the cache is enabled when the master accesses slave 3, and a cache replacement operation occurs, it may access slave 3 with a burst transmission of type WRAP and a burst length equal to the size of a cache line. Therefore, when selecting test cases to verify the target path, it is also necessary to pay attention to specific business scenarios, such as the performance when host 1 and host 2 simultaneously access slave 1, or when a host accesses a slave with certain specific protocol parameters. By extracting the architecture information filled in by the architecture engineer, the NoC path verification is automated. That is, the verification environment is automatically generated based on the architecture information, and the various paths and parameters are displayed in a GUI interface, allowing verification engineers to conveniently and intuitively verify these specific scenarios.

[0059] Therefore, this application discloses a path verification method for on-chip networks, including: extracting the architecture information of the on-chip network to be verified, generating a corresponding verification environment based on the architecture information; selecting a target path from the verification environment and determining the target path parameters through a graphical user interface; running corresponding test cases based on the target path, the target path parameters, and the business scenario, and obtaining the corresponding running results to complete the path verification of the on-chip network. It is evident that for different on-chip networks, only different architecture information files need to be filled in to generate corresponding verification environments, eliminating the need to generate separate verification environments for each on-chip network, reducing the repetitive workload and verification cycle for verification engineers; providing an intuitive graphical user interface allows verification engineers to arbitrarily select verification paths and path parameters, making operation convenient and enabling diverse path verification.

[0060] Reference Figure 3 As shown, this embodiment of the invention discloses a specific path verification method for on-chip networks. Compared with the previous embodiment, this embodiment further explains and optimizes the technical solution. Specifically:

[0061] Step S21: Extract the architecture information of the on-chip network to be verified, and generate a corresponding verification environment based on the architecture information.

[0062] Step S22: Select a preset number of target paths from the verification environment through the graphical user interface, and specify corresponding path parameters and / or default random path parameters for the target paths; determine the path parameters and / or the default random path parameters as target path parameters.

[0063] In this embodiment, based on the base sequence of each pathway generated by the verification environment, the GUI interface will display each pathway and parameter to the verification engineer. The verification engineer can then select the target pathway or input relevant parameters from the displayed pathways and parameters. It should be noted that the verification engineer can directly input corresponding commands through the human-computer interaction interface to perform selection or input operations, or can use external devices such as a mouse or keyboard to assist in selection or input. The specific selection or input parameters are as follows:

[0064] 1) Select one or more pathways that you want to verify;

[0065] 2) Specify parameters for the selected pathway. If no parameters are specified, the default is to randomly select parameters within a reasonable range of supported parameters, thereby verifying the specified parameters.

[0066] 3) Customize the test case name and run options for the current test case, such as coverage;

[0067] Step S23: Based on the target path, the target path parameters, and the business scenario, run the corresponding test cases and obtain the corresponding running results to complete the path verification of the on-chip network.

[0068] Therefore, the intuitive GUI interface provides a convenient way for verification engineers to select verification paths and parameters, making the operation easy and enabling the configurability of path test cases, thereby achieving diversity in path verification.

[0069] Reference Figure 4 As shown, this embodiment of the invention discloses a specific path verification method for on-chip networks. Compared with the previous embodiment, this embodiment further explains and optimizes the technical solution. Specifically:

[0070] Step S31: Extract the architecture information of the on-chip network to be verified, and generate a corresponding verification environment based on the architecture information.

[0071] Step S32: Select the target pathway and determine the target pathway parameters from the verification environment through the graphical user interface.

[0072] Step S33: Based on the target path, the target path parameters, and the business scenario, run the corresponding test cases and obtain the corresponding running results to complete the path verification of the on-chip network.

[0073] For more detailed processing procedures in steps S31, S32, and S33, please refer to the aforementioned disclosed embodiments; they will not be repeated here.

[0074] Step S34: Based on the running results, generate a simulation report containing waveform files, log files, test case regression results, and coverage files.

[0075] In this embodiment, the function generates various simulation report files based on the running results, such as waveform files, log files, regression result files, and HTML report files. Then, the simulation reports are displayed. Specifically, the simulation waveform files of the test cases are displayed to the verification engineer in waveform form through the view; the view log displays the log files; the view regression summary displays the regression result files; and the view html report displays the HTML report files of the test cases in HTML form to the verification engineer.

[0076] Step S35: Determine whether the simulation results in the simulation report meet the preset simulation target. If not, execute the step of selecting the target path from the verification environment and determining the target path parameters through the graphical user interface.

[0077] In this embodiment, when the simulation results in the simulation report do not meet the preset simulation goals issued by the verification engineer, or when the verification engineer wants to verify other pathways, a new pathway can be selected. The corresponding test cases will then be run automatically again, and a simulation report will be generated until the verification engineer achieves the predetermined goal. For different NoCs, only the architecture engineer needs to provide the corresponding architecture information, and the verification engineer can quickly obtain the verification environment for different NoCs and quickly implement pathway verification. This invention is simple to use, highly reusable, and provides intuitive simulation results, avoiding repetitive verification work for verification engineers facing different NoCs.

[0078] Reference Figure 5 As shown, the pathway verification includes four functional modules: cfg_gen, env_gen, tc_run, and report_gen.

[0079] The cfg_gen configuration information generation module is responsible for filling in and extracting architecture information, as well as generating the verification environment. It consists of three parts: arc_info, extract info, and cfg class. Arc_info is the NoC architecture information file filled in by the architect; extract info extracts the rc_info data; and cfg class is the final configuration class file used to generate the verification environment.

[0080] 2. The env_gen verification environment generation module is responsible for generating or updating the UVM (General Verification Methodology) verification environment based on the configuration information. It contains only one sub-module: uvm env gen, which generates the UVM verification environment based on the generated cfg class.

[0081] 3. The `tc_run` test case execution module is responsible for automatically running corresponding test cases in a GUI based on the pathways and scenarios selected by the verification engineer. It comprises three sub-modules: `tc select`, `comp / run argmodify`, and `run tcs`. `tc select` generates test cases based on the data pathway selected by the verification engineer through the GUI; `comp / run arg modify` modifies the compilation or simulation commands based on the compilation or simulation options selected by the verification engineer through the GUI, such as adding coverage, invoking the GUI for simulation, and modifying TCL files; and `run tcs` implements automated test case simulation.

[0082] The `report_gen` module, responsible for generating simulation report files, includes waveform files, log files, regression results, and coverage files based on the test case execution results. It offers multiple report formats and comprises five sub-modules: post-processing, view waveform, view log, view regression summary, and view HTML report. The post-processing module generates various simulation report files, such as waveform files, log files, regression result files, and HTML report files. The view module displays the waveform files, presenting the simulated waveforms of the test cases to the verification engineer. The view log displays the log files. The view regression summary displays the regression result files. The view HTML report displays the HTML report files of the test cases in HTML format.

[0083] Therefore, the automatic generation of various types of simulation reports, displayed clearly and intuitively, facilitates subsequent debugging and analysis by verification engineers. These three points enable an automated and rapid pathway verification process for NoCs, resulting in a high degree of automation and strong reusability throughout the invention process.

[0084] Reference Figure 6 As shown, this embodiment of the invention discloses a path verification device for an on-chip network, comprising:

[0085] Environment generation module 11 is used to extract the architecture information of the on-chip network to be verified and generate a corresponding verification environment based on the architecture information;

[0086] Parameter determination module 12 is used to select a target path from the verification environment and determine the target path parameters through a graphical user interface;

[0087] The path verification module 13 is used to run corresponding test cases based on the target path, the target path parameters, and the business scenario, and obtain the corresponding running results to complete the path verification of the on-chip network.

[0088] Therefore, this application discloses a path verification method for on-chip networks, including: extracting the architecture information of the on-chip network to be verified, generating a corresponding verification environment based on the architecture information; selecting a target path from the verification environment and determining the target path parameters through a graphical user interface; running corresponding test cases based on the target path, the target path parameters, and the business scenario, and obtaining the corresponding running results to complete the path verification of the on-chip network. It is evident that for different on-chip networks, only different architecture information files need to be filled in to generate corresponding verification environments, eliminating the need to generate separate verification environments for each on-chip network, reducing the repetitive workload and verification cycle for verification engineers; providing an intuitive graphical user interface allows verification engineers to arbitrarily select verification paths and path parameters, making operation convenient and enabling diverse path verification.

[0089] In some specific embodiments, the on-chip network path verification device may specifically include:

[0090] The information file generation unit is used to fill in the information file of the network-on-chip to be verified, which includes the number, name, interface protocol, and path parameters of the interface units that interface with the host and the interface units that interface with the slave.

[0091] In some specific embodiments, the environment generation module 11 may specifically include:

[0092] The information acquisition unit is used to extract the architecture information of the on-chip network to be verified in order to generate configuration information for configuring the verification environment.

[0093] A corresponding verification environment is generated based on the configuration information.

[0094] In some specific embodiments, the environment generation module 11 may specifically include:

[0095] The environment generation unit is used to simulate the transmission behavior of the host and slave connected to the on-chip network to be verified using the verification IP core, and generate corresponding paths to generate the corresponding verification environment; wherein, the path is used for the host and slave to transmit data through the on-chip network to be verified, the path protocol and the path parameters.

[0096] In some specific embodiments, the parameter determination module 12 may specifically include:

[0097] The parameter determination unit is used to select a preset number of target paths from the verification environment through a graphical user interface, and to specify corresponding path parameters and / or default random path parameters for the target paths; and to determine the path parameters and / or the default random path parameters as target path parameters.

[0098] In some specific embodiments, the on-chip network path verification device may specifically include:

[0099] The report generation unit is used to generate a simulation report containing waveform files, log files, test case regression results, and coverage files based on the running results.

[0100] In some specific embodiments, the on-chip network path verification device may specifically include:

[0101] The result judgment unit is used to determine whether the simulation results in the simulation report meet the preset simulation target. If not, the unit executes the step of selecting the target path from the verification environment and determining the target path parameters through the graphical user interface.

[0102] Furthermore, embodiments of this application also disclose an electronic device, Figure 7 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0103] Figure 7 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the on-chip network path verification method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0104] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0105] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0106] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0107] The operating system 221 manages and controls the various hardware devices and computer programs 222 on the electronic device 20 to enable the processor 21 to perform calculations and processing on the massive amounts of data 223 in the memory 22. The operating system 221 can be Windows Server, Netware, Unix, Linux, etc. The computer program 222, in addition to including a computer program capable of performing the on-chip network path verification method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, may further include computer programs capable of performing other specific tasks. The data 223 may include data received by the electronic device from external devices, as well as data collected by its own input / output interface 25.

[0108] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned on-chip network path verification method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0109] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0110] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in connection with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described functions using different methods for each specific application, but such implementation should not be considered beyond the scope of this application. The steps of the methods or algorithms described in connection with the embodiments disclosed herein can be implemented directly in hardware, software modules executed by a processor, or a combination of both. Software modules can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art.

[0111] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0112] The above provides a detailed description of the path verification method, apparatus, device, and storage medium for on-chip networks provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A path verification method for an on-chip network, characterized in that, include: Extract the architecture information of the on-chip network to be verified, and generate a corresponding verification environment based on the architecture information; wherein, when the architecture information changes, the verification environment is updated based on the changed architecture information; Select the target pathway and determine the target pathway parameters from the verification environment through a graphical user interface; Based on the target path, the target path parameters, and the business scenario, run the corresponding test cases and obtain the corresponding running results to complete the path verification of the on-chip network. The step of extracting the architecture information of the on-chip network to be verified and generating a corresponding verification environment based on the architecture information includes: Extract the architecture information of the on-chip network to be verified in order to generate configuration information for configuring the verification environment; A corresponding verification environment is generated based on the configuration information. The generation of the corresponding verification environment based on the architecture information includes: The verification IP core is used to simulate the transmission behavior of the host and slave connected to the on-chip network to be verified, and corresponding paths are generated to create a corresponding verification environment; wherein, the path is used for the host and slave to transmit data through the on-chip network to be verified, the path protocol and the path parameters; Before extracting the architecture information of the on-chip network to be verified, the process also includes: Fill in the information file of the network-on-chip to be verified, which includes the number, name, interface protocol, and path parameters of the interface units that interface with the host and the interface units that interface with the slave.

2. The path verification method for on-chip networks according to claim 1, characterized in that, The step of selecting the target path and determining the target path parameters from the verification environment through a graphical user interface includes: Select a preset number of target paths from the verification environment through the graphical user interface, and specify the corresponding path parameters and / or default random path parameters for the target paths; The path parameters and / or the default random path parameters are determined as the target path parameters.

3. The path verification method for an on-chip network according to any one of claims 1 or 2, characterized in that, After running the corresponding test cases based on the target path, the target path parameters, and the business scenario, and obtaining the corresponding running results, the process also includes: Based on the results, a simulation report is generated that includes waveform files, log files, test case regression results, and coverage files.

4. The path verification method for on-chip networks according to claim 3, characterized in that, After generating a simulation report containing waveform files, log files, test case regression results, and coverage files based on the execution results, the process further includes: Determine whether the simulation results in the simulation report meet the preset simulation target. If not, execute the step of selecting the target path from the verification environment and determining the target path parameters through the graphical user interface.

5. A path verification device for an on-chip network, characterized in that, include: An environment generation module is used to extract the architecture information of the on-chip network to be verified and generate a corresponding verification environment based on the architecture information; wherein, when the architecture information changes, the verification environment is updated based on the changed architecture information; The parameter determination module is used to select a target path from the verification environment and determine the target path parameters through a graphical user interface. The path verification module is used to run corresponding test cases based on the target path, the target path parameters, and the business scenario, and obtain the corresponding running results to complete the path verification of the on-chip network. The environment generation module specifically includes: An information acquisition unit is used to extract the architecture information of the on-chip network to be verified in order to generate configuration information for configuring the verification environment; and to generate a corresponding verification environment based on the configuration information. The environment generation unit is used to simulate the transmission behavior of the host and slave connected to the on-chip network to be verified using the verification IP core, and generate corresponding paths to generate the corresponding verification environment; wherein, the path is used for the host and slave to transmit data through the on-chip network to be verified, the path protocol and the path parameters; The information file generation unit is used to fill in the information file of the network-on-chip to be verified, which includes the number, name, interface protocol, and path parameters of the interface units that interface with the host and the interface units that interface with the slave.

6. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the on-chip network path verification method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, Used to store a computer program; wherein, when the computer program is executed by a processor, it implements the steps of the on-chip network path verification method as described in any one of claims 1 to 4.

Images