Network-on-chip debugging method and device, electronic equipment and readable storage medium

Abstract

The invention discloses a debugging method and device for a network-on-chip, electronic equipment and a readable storage medium, and relates to the technical field of the network-on-chip, and the method comprises the steps: automatically carrying out the function verification and performance debugging of the network-on-chip through a log file and a signal waveform file, finding out the reasons of function errors and performance substandard, and carrying out the debugging of the performance of the network-on-chip. Therefore, a user can be helped to quickly and efficiently complete the function debugging and performance analysis of the network-on-chip, so that the verification efficiency of verifying the network-on-chip can be improved, and the verification period can be shortened; therefore, the problem of low efficiency of function debugging and performance analysis of the network-on-chip in the prior art is solved.

Description

Technical Field

[0001] The present application relates to the technical field of network-on-chip, and in particular, to a debugging method, device, electronic device and readable storage medium for a network-on-chip. Background Art

[0002] With the high integration and rapid development of SoC (System on Chip), the application requirements of SoC are becoming more and more abundant, and SoC needs to integrate more and more IP (Intellectual Property Core) for different applications. Thus, higher requirements are put forward for on-chip communication. And the network-on-chip (NoC) replaces the traditional bus architecture, uses a transaction-based communication architecture to route the transactions initiated by the host to the slave, and returns the response of the slave to the host.

[0003] With the increase in the scale of the SoC chip and the increase in the number of IPs in the SoC chip, the scale of the NoC also increases accordingly. Correspondingly, these also increase the difficulty of functional debugging and performance analysis of the network-on-chip, and thus lead to low efficiency of functional debugging and performance analysis of the network-on-chip. Summary of the Invention

[0004] The present application provides a debugging method, device, electronic device and readable storage medium for a network-on-chip, so as to at least solve the problem of low efficiency of functional debugging and performance analysis of the network-on-chip in the related art.

[0005] The present application provides a debugging method for a network-on-chip, including: obtaining a log file and a signal waveform file, where the log file and the signal waveform file are generated during the process of the test platform debugging the network-on-chip through test cases; based on the data corresponding to the log file and the signal waveform file, performing functional verification on multiple functional dimensions of the network-on-chip to obtain functional verification results under each functional dimension; based on the data corresponding to the log file and the signal waveform file, performing performance debugging on multiple performance dimensions of the network-on-chip to obtain target performance parameters of the network-on-chip; fusing the functional verification results and / or the target performance parameters to generate a network debugging result.

[0006] The present application also provides a debugging device for a network-on-chip, including: a first acquisition module, configured to acquire a log file and a signal waveform file, where the log file and the signal waveform file are generated during the process of the test platform debugging the network-on-chip through test cases; a function verification module, configured to perform function verification on multiple function dimensions of the network-on-chip based on the data corresponding to the log file and the signal waveform file, so as to obtain function verification results under each function dimension; a performance debugging module, configured to perform performance debugging on multiple performance dimensions of the network-on-chip based on the data corresponding to the log file and the signal waveform file, so as to obtain target performance parameters of the network-on-chip; a debugging result generation module, configured to fuse the function verification results and / or the target performance parameters to generate a network debugging result.

[0007] The present application also provides an electronic device, including: a memory, configured to store a computer program; a processor, configured to implement the steps of any one of the above-mentioned debugging methods for the network-on-chip when executing the computer program.

[0008] The present application also provides a computer-readable storage medium, in which a computer program is stored, where the computer program implements the steps of any one of the above-mentioned debugging methods for the network-on-chip when being executed by a processor.

[0009] In the debugging method for the network-on-chip provided by the embodiments of the present application, the test platform generates a log file and a signal waveform file during the process of debugging the network-on-chip through test cases, and the debugging platform acquires the log file and the signal waveform file. Based on the data corresponding to the acquired log file and signal waveform file, it is possible to perform function verification on the network-on-chip in multiple function dimensions to obtain function verification results under each function dimension, and it is also possible to perform performance verification on the network-on-chip in multiple performance dimensions to obtain target performance parameters of the network-on-chip; finally, by fusing the function verification results and / or the target performance parameters, a network debugging result is obtained. This solution can automatically perform function verification and performance debugging on the network-on-chip only through the log file and the signal waveform file, find the reasons for function errors and performance non-compliance, and does not need to obtain a lot of other information. Therefore, it can help users quickly and efficiently complete the function debugging and performance analysis of the network-on-chip, thereby improving the verification efficiency of verifying the network-on-chip and shortening the verification cycle, and further solving the problem of low efficiency in function debugging and performance analysis of the network-on-chip in the related art. Description of the Drawings

[0010] In order to more clearly illustrate the embodiments of the present application, the following will briefly introduce the drawings required for the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0011] Figure 1 Schematic diagram of the architecture of a debugging system for a network-on-chip provided by an embodiment of the present application;

[0012] Figure 2 Schematic flow chart of a debugging method for a network-on-chip provided by an embodiment of the present application;

[0013] Figure 3 Schematic flow chart of another debugging method for a network-on-chip provided by an embodiment of the present application;

[0014] Figure 4 Schematic diagram of a network node provided by an embodiment of the present application;

[0015] Figure 5 Schematic diagram of a waveform comparison and analysis provided by an embodiment of the present application;

[0016] Figure 6 Schematic diagram of an interface for InitiatorA to access TargetB provided by an embodiment of the present application;

[0017] Figure 7 Schematic diagram of a bandwidth utilization rate provided by an embodiment of the present application;

[0018] Figure 8 Schematic diagram of an interface for InitiatorA to access TargetB and InitiatorB to access TargetB provided by an embodiment of the present application;

[0019] Figure 9 Schematic diagram of an average delay provided by an embodiment of the present application;

[0020] Figure 10 Schematic diagram of an interface between InitiatorA and TargetB provided by an embodiment of the present application;

[0021] Figure 11 Schematic diagram of a parameter of the number of outstanding provided by an embodiment of the present application;

[0022] Figure 12 Schematic flow chart of yet another debugging method for a network-on-chip provided by an embodiment of the present application;

[0023] Figure 13 Schematic flow chart of a debugging device for a network-on-chip provided by an embodiment of the present application;

[0024] Figure 14 Schematic diagram of the structure of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0025] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0026] It should be noted that in the description of the present application, the terms "include", "comprise" or any other variant thereof are intended to cover a non-exclusive inclusion, such that a process, method, article or device including a series of elements not only includes those elements but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in the present application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0027] With the high integration and rapid development of the SoC (System on Chip), the application requirements of the SoC are becoming more and more abundant, and the SoC needs to integrate more and more IPs (Intellectual Property Cores) for different applications. Thus, higher requirements are put forward for on-chip communication. The Network on Chip (NoC) replaces the traditional bus architecture and uses a transaction-based communication architecture to route the transactions initiated by the host to the slave and return the responses of the slave to the host.

[0028] With the increase in the scale of the SoC chip and the increase in the number of IPs in the SoC chip, the scale of the NoC also increases accordingly. Correspondingly, these also increase the difficulty of functional debugging and performance analysis of the on-chip network, and thus lead to a lower efficiency of functional debugging and performance analysis of the on-chip network.

[0029] On the one hand, with the increase in the scale of the SoC chip, various problems may be encountered in the process of verifying the functional correctness of the NoC, which results in a large workload and high complexity in debugging the on-chip network. For example, the behavior of the host or the slave violates the communication protocol, the access result of the host or the response result of the slave does not match the expectation, and access timeout, etc. The reasons for these errors are diverse, and users need to analyze them one by one, and the possibility of occurrence increases with the increase in the number of hosts and / or slaves and the types of protocols.

[0030] On the other hand, common performance parameters of the NoC include latency, bandwidth, and the number of outstanding transactions (outstanding count parameter), etc., which are key parts affecting the performance of the entire SoC. As the scale of the SoC chip increases, the time required to debug the performance parameters of the on-chip network to the desired performance parameters becomes longer. For example, the performance of the CPU is directly related to the access latency. For such IPs, the path latency from them to the Memory is very important, and the NoC must meet the maximum path latency they can accept. The performance of the GPU is directly related to the bandwidth. For such IPs, the path bandwidth from them to the Memory is very important, and the NoC must meet the minimum bandwidth requirements they can accept. Of course, there are also some IPs that are more concerned about real-time performance, such as video modules, which will continuously transmit a large amount of data over a long period of time. For such IPs, the NoC needs to adjust both the latency and the bandwidth simultaneously to meet the maximum path latency and minimum bandwidth requirements they can accept, so as to ensure that this real-time process does not fail. For the NoC, how to balance the latency and bandwidth of each IP access so that the performance parameters of the entire SoC reach the optimal performance parameters often requires multiple iterations, tests, and analyses.

[0031] In view of this, embodiments of the present application provide a debugging method, device, electronic device, and readable storage medium for an on-chip network. This solution can analyze the data corresponding to the log file and the signal waveform file to find the reasons for the functional errors and / or performance non-compliance of the on-chip network, thereby helping users quickly and efficiently complete the functional debugging and performance analysis of the NoC. Secondly, this solution can also be integrated into the test environment process. The integration method is simple, with high reusability, and can automatically help users perform functional debugging and performance analysis, improving the verification efficiency and shortening the verification cycle.

[0032] For ease of understanding, the application architecture of the debugging method, device, electronic device, and readable storage medium for the on-chip network provided by the present application will be briefly introduced below.

[0033] Figure 1 It is a schematic diagram of the architecture of a debugging system for an on-chip network provided by an embodiment of the present application. The debugging system for the on-chip network includes a test platform and a debugging platform.

[0034] First, obtain the architecture definition information of the test platform and the debug platform. This architecture definition information is used to generate the test platform, debug platform, test cases, ENV file, and NoC configuration tool. The architecture definition information includes the design file information to be tested of the network-on-chip, clock signal information, reset signal information, and the network interface unit information corresponding to each network interface unit of the network-on-chip. Among them, the network interface unit is used to connect to the host or slave, and both the host and slave belong to the verification intellectual property core. The NoC configuration tool is used to generate the entity of the NoC, that is, to generate the code of the NoC. The ENV file (verification intellectual property core component file) is a component file containing VIP (verification intellectual property core). The ENV file is used to complete the instantiation and connection of VIP components. For example, instantiate Master0 to MasterN VIP and Slave0 to SlaveN VIP, and configure the configuration information of each VIP to the corresponding VIP, where Master is the host and Slave is the slave.

[0035] After that, the test platform debugs the network-on-chip through test cases and generates a log file and a signal waveform file.

[0036] Finally, the debug platform obtains the log file and the signal waveform file, and sends the obtained log file and signal waveform file to the function debug module and the performance debug module. The function debug module uses protocol analysis tools, address analysis tools, slave status check tools, and waveform comparison analysis tools to analyze the data corresponding to the obtained log file and signal waveform file, and verifies the functions of the network-on-chip in multiple function dimensions to obtain the function verification results in each function dimension. The performance debug module uses bandwidth analysis tools, delay analysis tools, and outstanding analysis tools to analyze the data corresponding to the obtained log file and signal waveform file, and verifies the performance of the network-on-chip in multiple performance dimensions to obtain the target performance parameters of the network-on-chip. By fusing the function verification results and / or the target performance parameters, the network debug result is obtained.

[0037] According to an embodiment of the present invention, an embodiment of a method for debugging a network-on-chip is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0038] In this embodiment, a method for debugging a network-on-chip is provided, which can be applied to the above-mentioned debug platform. Figure 2 It is a flowchart of the method for debugging a network-on-chip according to an embodiment of the present invention, as Figure 2 shown, and this process includes the following steps:

[0039] Step S201: Obtain a log file and a signal waveform file. The log file and the signal waveform file are generated during the process of debugging the on-chip network by the test platform through test cases.

[0040] A log file is a file that records the activities of a system, application, or device. It records various events, operations, and related information in chronological order to facilitate tasks such as troubleshooting, system monitoring, security auditing, and performance analysis for system administrators, developers, or other relevant personnel. The log file in this embodiment is used to record various transactions, signal status information, and time information during the operation of the on-chip network, including but not limited to these.

[0041] A signal waveform file is a file that stores information related to signal waveforms, recording the amplitude values of signals changing with variables such as time or space. The signal waveform file in this embodiment is used to record the waveforms of communication signals over time during the communication process between the host and the slave.

[0042] Regarding the acquisition methods of the log file and the signal waveform file, the log file and the signal waveform file can be obtained from the test platform; the log file can also be obtained from the log module built into the SoC, and the signal waveform file can be obtained from the on-chip debugging module built into the SoC.

[0043] Step S202: Based on the data corresponding to the log file and the signal waveform file, perform functional verification on multiple functional dimensions of the on-chip network to obtain the functional verification results for each functional dimension.

[0044] The functional dimensions can be the communication protocol dimension, the communication address dimension, the slave status dimension, and the signal waveform dimension. Therefore, based on the data corresponding to the log file and the signal waveform file, functional verification of the on-chip network can be performed from the communication protocol dimension, the communication address dimension, the slave status dimension, and the signal waveform dimension.

[0045] Step S203: Based on the data corresponding to the log file and the signal waveform file, perform performance debugging on multiple performance dimensions of the on-chip network to obtain the target performance parameters of the on-chip network.

[0046] The performance dimensions can be the bandwidth dimension, the latency dimension, and the outstanding dimension. Therefore, based on the data corresponding to the log file and the signal waveform file, performance verification of the on-chip network can be performed from the bandwidth dimension, the latency dimension, and the outstanding dimension, where the outstanding dimension refers to the dimension of the number of unresponsive transactions.

[0047] Step S204: Fuse the functional verification results and / or the target performance parameters to generate the network debugging result.

[0048] The network debugging result is obtained by fusing the function verification result and / or the target performance parameter based on a preset fusion rule. The preset fusion rule can be a rule for fusing the function verification result and the target performance parameter that is set in advance.

[0049] The network debugging result may include the result of whether the function verification in the communication protocol dimension is passed. If the function verification in the communication protocol dimension fails, the cause of the problem and the method to solve the problem are determined; if the function verification in the communication protocol dimension is passed, it is determined whether the function verification in the communication address dimension is passed; if the function verification in the communication address dimension fails, the cause of the problem and the method to solve the problem are determined; if the function verification in the communication address dimension is passed, it is determined whether the function verification in the slave state dimension is passed; if the function verification in the slave state dimension fails, the cause of the problem and the method to solve the problem are determined; if the function verification in the slave state dimension is passed, the analysis in the signal waveform dimension is performed to obtain the analysis result in the signal waveform dimension, and so on. The network debugging result may also include the target performance parameter of the on-chip network.

[0050] In the on-chip network debugging method provided by the embodiments of the present application, during the process of debugging the on-chip network through test cases by the test platform, a log file and a signal waveform file are generated. The debugging platform acquires the log file and the signal waveform file. Thus, based on the data corresponding to the acquired log file and signal waveform file, the function verification of the on-chip network can be performed in multiple function dimensions to obtain the function verification results in each function dimension, and the performance verification of the on-chip network can be performed in multiple performance dimensions to obtain the target performance parameter of the on-chip network; finally, by fusing the function verification result and / or the target performance parameter, the network debugging result is obtained. This solution can automatically perform function verification and performance debugging on the on-chip network only through the log file and the signal waveform file, find the reasons for function errors and performance non-compliance, without obtaining a lot of other information. Therefore, it can help users quickly and efficiently complete the function debugging and performance analysis of the on-chip network, thereby improving the verification efficiency of verifying the on-chip network and shortening the verification cycle, and further solving the problem of low efficiency in the function debugging and performance analysis of the on-chip network.

[0051] Using the above on-chip network debugging method, if a functional anomaly occurs in the on-chip network, the function debugging module extracts the corresponding signal waveform file and log file. The protocol analysis tool, address range analysis tool, slave status check tool, and waveform comparison analysis tool in the function debugging module analyze the signal waveform file and log file to determine the cause of the error. If the cause of the error is the test platform, the test platform is debugged and correct test cases are regenerated. If the error occurs at the module level and the test cases are generated by the VIP, the function debugging module will analyze the test / sequence file (network debugging result) and correct possible errors. If the error occurs at the subsystem or chip level and the test cases are generated by the host or slave connected to the NoC, the function debugging module will report the module where the error occurs and the error type, and it will be handled by the person in charge of the corresponding host or slave. If the cause of the error is the on-chip network, the function debugging module can automatically call the NoC configuration tool to generate the code corresponding to the new on-chip network and automatically complete the test. If there is no problem with both the test platform and the on-chip network, an error report is generated for manual analysis by the corresponding user. If the performance of the on-chip network is insufficient, the performance debugging module extracts the corresponding signal waveform file and log file, and the bandwidth analysis tool, delay analysis tool, and outstanding analysis tool in the performance debugging module respectively analyze the potential factors for the insufficient performance parameters of their respective performance parameters.

[0052] In this embodiment, a debugging method for an on-chip network is provided, which can be applied to the above debugging platform. Figure 3 It is a flowchart of the debugging method for an on-chip network according to an embodiment of the present invention, as Figure 3 shown, and the process includes the following steps:

[0053] Step S301, obtain a log file and a signal waveform file, where the log file and the signal waveform file are generated during the process of the test platform debugging the on-chip network through test cases. For details, please refer to Figure 2 Step S201 of the embodiment shown, which will not be elaborated here.

[0054] Step S302, based on the data corresponding to the log file and the signal waveform file, perform function verification on multiple function dimensions of the on-chip network to obtain function verification results under each function dimension.

[0055] Specifically, the above step S302 includes:

[0056] Step S3021, based on the error information corresponding to the error time in the log file, determine the target signal corresponding to the error time from the signal waveform file.

[0057] The target signal can be a read signal, a write signal, a storage signal, etc. The error information can include data transmission errors, network congestion errors, node failure errors, etc.

[0058] The log file records various events, signal status information, and time information during the operation of the network-on-chip. Therefore, based on the error information corresponding to the error time in the log file, the target signal corresponding to the error time can be determined from the signal waveform file.

[0059] Step S3022: Determine whether the target signal violates the communication protocol.

[0060] The process of determining whether the target signal violates the communication protocol can include: first, determine the communication protocol of the target signal. Then, determine whether the communication protocol of the target signal conforms to the communication protocol specified by the network-on-chip. If it conforms, it is determined that the target signal does not violate the communication protocol; if it does not conform, it is determined that the target signal violates the communication protocol.

[0061] Step S3023: When the target signal violates the communication protocol, check and correct the test case to generate a functional verification result.

[0062] To facilitate the user to efficiently and quickly debug the function of the network-on-chip, when the target signal violates the communication protocol, the specific error details can also be printed to the error report, so as to generate a functional verification result including the error report.

[0063] For the protocol analysis tool, its purpose is to check whether the communication protocol corresponding to the transaction initiated by the host matches the communication protocol defined by the corresponding Initiator NIU (network interface unit docked with the host), and whether the communication protocol corresponding to the transaction responded by the slave matches the communication protocol defined by the corresponding Target NIU (network interface unit docked with the slave). In an optional implementation manner, the corresponding passive VIP (passive verification intellectual property core) can be integrated into the protocol analysis tool. The passive VIP can support the analysis of four protocols, namely AXI (Advanced eXtensible Interface, high-performance extended bus interface), AHB (Advanced High Performance Bus, advanced high-performance bus), APB (Advanced Peripheral Bus, advanced peripheral bus), and NSP (NoC socket protocol, network-on-chip interface protocol). Therefore, the passive VIP can locate the target signal corresponding to the error time from the signal waveform file according to the error time and error information in the log file to check whether the target signal violates the communication protocol.

[0064] Step S303: Based on the data corresponding to the log file and the signal waveform file, perform performance debugging on multiple performance dimensions of the on-chip network to obtain the target performance parameters of the on-chip network. For details, please refer to Figure 2 Step S203 of the embodiment shown.

[0065] Step S304: Integrate the functional verification result and / or the target performance parameters to generate a network debugging result. For details, please refer to Figure 2 Step S204 of the embodiment shown, which will not be elaborated here.

[0066] In the debugging method of the on-chip network provided in this embodiment, through the error information corresponding to the error time in the log file, the target signal corresponding to the error time can be located from the signal waveform file. By determining whether the target signal violates the communication protocol, it is determined whether there is a communication protocol error in the on-chip network, so as to implement functional verification of the on-chip network. Based on the log file and the signal waveform file, performance debugging of the on-chip network can also be performed. In this way, this solution can automatically perform functional verification and performance debugging on the on-chip network only based on the log file and the signal waveform file, find the reasons for functional errors and performance non-compliance, without obtaining a lot of other information. Therefore, it can help users quickly and efficiently complete the functional debugging and performance analysis of the on-chip network, thereby improving the verification efficiency of verifying the on-chip network and shortening the verification cycle, and then solving the problem of low efficiency in the functional debugging and performance analysis of the on-chip network.

[0067] In order to comprehensively perform functional verification on the on-chip network, when the target signal does not violate the communication protocol, it is also necessary to check the communication address between the host and the slave. Based on this, in some embodiments, when the target signal does not violate the communication protocol, obtain the address mapping table; based on the address mapping table, the communication protocol of the host and the received error type, and the communication protocol of the slave and the received error type, determine whether the communication address between the host and the slave is correct; when the communication address between the host and the slave is incorrect, check and correct the test case to generate a functional verification result.

[0068] The address mapping table can be obtained from the architecture definition information. After obtaining the address mapping table, the address range from the host to the slave, the valid address range of the slave, and the reserved address range can be generated based on the address mapping table.

[0069] In the above implementation, based on the address mapping table, the communication protocol of the host, the error type received by the host, the communication protocol of the slave, and the error type received by the slave, it is possible to analyze in detail and quickly and efficiently whether the communication address between the host and the slave is correct.

[0070] The address range analysis tool in the debugging platform can be used to determine whether the communication address between the host and the slave is correct. That is, through the address range analysis tool, it can be checked whether the address of the transaction initiated by the host is within the Initiator address range corresponding to the slave to be accessed, and whether the address received by the slave after being transmitted through the NoC is within the Target address range corresponding to the slave, so as to determine whether the communication address between the host and the slave is correct.

[0071] Checking whether the address of the transaction initiated by the host is within the Initiator address range corresponding to the slave to be accessed is to ensure that the transaction initiated by the host has the correct target address. If the address of the transaction initiated by the host exceeds the Initiator address range corresponding to the slave, it means that the host may have incorrectly initiated a transaction to an irrelevant slave, or the address of the initiated transaction is simply invalid, which will lead to communication errors or abnormal behavior of the on-chip network.

[0072] For the communication of the on-chip network, checking whether the address received by the slave is within the Target address range corresponding to the slave is to verify whether the address of the transaction initiated by the host remains correct and valid after being transmitted through the NoC. If the address received by the slave is not within its Target address range, it means that the address of the transaction initiated by the host has an error during the transmission process, resulting in the slave may not be able to correctly process the transaction initiated by the host, thereby affecting the function of the entire on-chip system.

[0073] In some alternative embodiments, when the communication address between the host and the slave is correct, based on the start time of the transaction initiated by the host obtained from the log file and / or the type of error response feedback by the network interface unit of the slave, it is determined whether the slave is in a workable state; when the slave is not in a workable state, the test case is checked and corrected, a functional verification result is generated, and the slave is configured based on the slave preset file to make the slave in a workable state, and the slave preset file is used to define the conditions for the slave to be in a workable state.

[0074] The slave preset file is used to define the conditions for the slave to be in a workable state. For example, the reset signal of the slave is released, the power on signal is valid, and the enable status register is valid, etc.

[0075] The slave status check tool in the debugging platform can be used to detect whether the slave is in a working state, that is, to check whether the slave has been pre - placed in a ready state before being accessed. In the actual communication process, after receiving a transaction initiated by the master, the slave needs to make corresponding responses according to the transaction type. Checking whether the slave status is in a working state can determine whether the slave can generate the correct response signal at the correct time according to the specified communication protocol. For example, for a read transaction initiated by the master, whether the slave can timely feedback the requested data to the master; for a write transaction initiated by the master, whether the slave should return an acknowledgement signal after completing the data writing.

[0076] Based on the start time of the transaction initiated by the master obtained from the log file and / or the type of error response feedback by the slave's network interface unit, it is possible to accurately and efficiently determine whether the slave is in a working state. When it is determined that the slave is not in a working state, checking and correcting the test cases helps to quickly locate possible problems, avoid the situation that the slave is not in a working state due to errors in the test cases, and improve the efficiency of functional verification of the network - on - chip.

[0077] Starting from the start time of the transaction initiated by the Initator NIU, if no response from the slave to this transaction is received within the configured monitoring time - window threshold value, it is considered that the slave has timed out and not responded. The possible reason for the error is that the slave is in an unprepared state. Based on this starting point, in some alternative implementation manners, determining whether the slave is not in a working state based on the start time of the transaction initiated by the master obtained from the log file and / or the error type feedback by the slave includes: obtaining the time - window threshold value; obtaining the start time of the transaction initiated by the master from the log file; starting from the start time, after passing the time - window threshold value, if the slave does not respond to the transaction initiated by the master, determining that the slave is not in a working state.

[0078] In the above implementation manner, if the slave still does not respond to the transaction initiated by the master after exceeding the time - window threshold value, it is possible that the slave has not received the transaction initiated by the master, or the slave is not in a working state. If the slave has not received the transaction initiated by the master, it may be that the address of the transaction initiated by the master is not within the Initiator address range corresponding to the slave, or the address received by the slave is not within the Target address range corresponding to the slave. For this situation, the address - range analysis tool will report an error. Therefore, at this time, if the slave still does not respond to the transaction initiated by the master after exceeding the time - window threshold value, it means that the slave is not in a working state. In this way, this solution can efficiently and quickly determine whether the slave is in a working state.

[0079] In some optional embodiments, when the communication protocol of the slave is the first communication protocol and the network interface unit of the slave feeds back a slave error response, it is determined that the slave is not in a working state; when the communication protocol of the slave is the third communication protocol or the fourth communication protocol and the network interface unit of the slave feeds back a slave error response, it is determined that the slave is not in a working state.

[0080] The first communication protocol is the AXI protocol, the third communication protocol is the AHB protocol, and the fourth communication protocol is the APB protocol.

[0081] When the communication protocol of the slave is the AXI protocol, if the network interface unit of the slave feeds back a slave error response, that is, the SLVEER response, there may be two error reasons at this time. One is that the host violates the communication protocol when accessing the slave, and the other is that the slave is not in a working state. For the type of error where the host violates the communication protocol when accessing the slave, the protocol analysis tool will report an error and correct the transaction initiated by the host. It can be seen that when the communication protocol of the slave is the AXI protocol, if the network interface unit of the slave feeds back a slave error response, that is, the SLVEER response, it means that the slave is not in a working state.

[0082] When the communication protocol of the slave is the AHB protocol or the APB protocol, if the network interface unit of the slave feeds back a slave error response, that is, the SLVEER response, there may be three error reasons. One is that the transaction initiated by the host accesses the reserved address range of the slave. For this case, the protocol analysis tool will report an error and correct the transaction. Another is that the host violates the communication protocol when accessing the slave. For this case, the protocol analysis tool will also report an error and correct the transaction. The third is that the slave is not in a working state.

[0083] In this way, based on the communication protocol of the slave and the error type fed back by the network interface unit of the slave, this solution can simply and accurately analyze whether the slave is in a working state.

[0084] Optionally, when it is determined that the slave is not in a working state, based on the conditions for the slave to be in a working state defined in the slave preset file, it can be checked in turn which reasons cause the slave not to be in a working state. For example, whether the signals or registers corresponding to the slave are not in a valid state, etc. When the reasons for the slave not to be in a working state are checked, the slave can be configured based on the slave preset file so that the slave is in a working state. When it is determined that the slave is not in a working state, the time threshold can also be set again to wait for the slave to enter a working state, and the above steps can be used again to check whether the slave is in a working state.

[0085] In some alternative embodiments, when the slave is in a workable state, obtain a comparison control file corresponding to a test case. The comparison control file is used to define each network node for test case checking and the priority of each network node. Each network node is a network node of the network-on-chip; obtain the signal waveforms of each network node from the signal waveform file; according to the priority of each network node in the comparison control file, compare the signal waveforms of each network node with the corresponding reference waveforms; in the case where the signal waveforms of one or more network nodes are inconsistent with the corresponding reference waveforms, check and correct the test case, generate a functional verification result, and adjust the configuration parameters of the test platform and the configuration parameters of the network-on-chip.

[0086] As Figure 4 shown, for the network-on-chip corresponding to Initiator (the initiator of the transaction) A, Initiator B, Target (the receiver of the transaction) A, Target B, and Target C, the network nodes ( Figure 4 the intersection points of the network paths represented by circles in Figure 4 ) can be the intersection points of the network paths between the host and the slave. Of course, the network nodes are not limited to being

[0087] the intersection points of the network paths represented by circles in

[0088] The intersection points of the network paths represented by circles in Figure 5 the network nodes can also be set at points on the network path according to various communication requirements. Figure 5The signal(A) and signal(A_REF) in it, and display the moments t1 and t1_ref when they are inconsistent. At the same time, list all the signals with inconsistent comparisons in the box where the signal is displayed. For example, signal A, signal B, signal C, signal D, and signal E. Of course, the user can also select other signals that need to be displayed according to needs. For example, as Figure 5 shown, since the user selects signal A and signal B at the same time, so Figure 5 in the interface shown, signal(B) and signal(B_REF) are also displayed, and the moments t2 and t2_ref when they are inconsistent are shown. Among them, signal(A_REF) refers to signal A, that is, the reference signal corresponding to signal(A), and signal(B_REF) refers to signal B, that is, the reference signal corresponding to signal(B).

[0089] In the actual application process, the user can adjust the test platform or modify the DUT according to experience without opening the log file and the signal waveform file based on the waveform comparison results displayed on the user interface. At the same time, the error results and adjustment measures with inconsistent waveform analysis at this time can also be saved to the large model database, so that the waveform comparison analysis tool can learn and train from this, so as to perform waveform analysis more accurately in the future.

[0090] In the above implementation method, according to the priorities of each network node set in the comparison control file, the signal waveforms of each network node are compared with the corresponding reference waveforms, which can improve the efficiency of waveform analysis. At the same time, comparing and analyzing the signal waveform of the network node with the reference waveform corresponding to the network node can more intuitively analyze the deviation between the actual operation of the network node and the expectation, and can help the user more conveniently determine the cause of the error.

[0091] In some alternative embodiments, determining whether the communication address between the host and the slave is correct based on the address mapping table, the communication protocol of the host and the received error type, and the communication protocol of the slave and the received error type includes: when the network interface unit of the host receives a decoding error response and the communication protocol of the host is the first communication protocol or the second communication protocol, determining whether the address corresponding to the transaction initiated by the host is correct based on the address corresponding to the transaction initiated by the host and the address mapping table; when the network interface unit of the host receives a slave error response, the communication protocol of the host is the first communication protocol or the second communication protocol, the communication protocol of the slave is the third communication protocol or the fourth communication protocol, and the network interface unit of the slave feeds back the slave error response, if the address corresponding to the transaction initiated by the host is within the reserved address range of the slave, determining that the address corresponding to the transaction initiated by the host is incorrect, and the reserved address range of the slave is generated based on the address mapping table; when the network receiving unit of the host receives a slave error response, the communication protocol of the host is the third communication protocol or the fourth communication protocol, the communication protocol of the slave is the first communication protocol, and the network interface unit of the slave feeds back a decoding error response, determining that the address corresponding to the transaction initiated by the host is incorrect; when the network interface unit of the host receives a slave error response, the communication protocol of the host is the third communication protocol or the fourth communication protocol, the communication protocol of the slave is the third communication protocol or the fourth communication protocol, and the network interface unit of the slave feeds back the slave error response, if the address corresponding to the transaction initiated by the host is within the reserved address range of the slave, determining that the address corresponding to the transaction initiated by the host is incorrect.

[0092] The second communication protocol may be the NSP protocol.

[0093] When the communication protocol of the host is the AXI protocol or the NSP protocol, if the network interface unit of the host receives a decoding error response, i.e., a DECRR response, there may be two possible error reasons at this time. One is that the transaction initiated by the host accesses the reserved address range of the NoC, and the other is that it accesses the reserved address range of a slave with the communication protocol of the AXI protocol or the NSP protocol. At this time, it is necessary to combine the address mapping table and the address corresponding to the transaction initiated by the host to specifically determine which type of error it belongs to. For example, it can be determined whether the address corresponding to the transaction initiated by the host is within the reserved address range of the NoC or within the reserved address range of the slave.

[0094] When the communication protocol of the host is the AXI protocol or the NSP protocol, if the host network interface unit receives a slave error response, that is, a SLVERR response, there may be two error reasons. One is that the transaction initiated by the host violates the communication protocol, and in this case, the protocol analysis tool will report an error and correct the transaction. The other is that if the communication protocol of the slave is the AXI protocol and the slave issues a SLVERR response, this does not belong to the address range error type.

[0095] When the communication protocol of the host is the AXI protocol or the NSP protocol, if the host network interface unit receives a slave error response, that is, a SLVERR response, the communication protocol of the slave is the AHB protocol or the APB protocol, and the slave issues a SLVERR response, then the address range analysis tool further determines whether the address accessed by the transaction initiated by the host is the reserved address range of the slave. If it belongs, it is determined that the address corresponding to the transaction initiated by the host is incorrect, that is, the communication address between the host and the slave is incorrect; if it does not belong, it does not belong to the address range error type.

[0096] When the communication protocol of the host is the APB protocol or the AHB protocol, if the host's network interface unit receives a slave error response, that is, a SLVERR response, there may be two error reasons. One is that the transaction initiated by the host violates the communication protocol, and in this case, the protocol analysis tool will report an error and correct the transaction. The other is that if the communication protocol of the slave is the AXI protocol and the network interface unit of the slave issues a SLVERR response, it does not belong to the address range error type; if the network interface unit of the slave issues a DECERR response, it has accessed the reserved address range of the slave. If the communication protocol of the slave is the AHB protocol or the APB protocol and the network interface unit of the slave issues a SLVERR response, then the address range analysis tool needs to further determine whether the address corresponding to the transaction initiated by the host is the reserved address range of the slave. If it belongs, it is determined that the address corresponding to the transaction initiated by the host is incorrect, that is, the communication address between the host and the slave is incorrect; if it does not belong, it does not belong to the address range error type.

[0097] In the above implementation method, by analyzing the communication protocol of the host, the error type received by the host, the communication protocol of the slave, and the error type received by the slave, it is possible to more accurately determine whether the communication address between the host and the slave is correct and improve the efficiency of determining whether the communication address between the host and the slave is correct.

[0098] In some embodiments, based on the data corresponding to the log file and the signal waveform file, performance debugging is performed on multiple performance dimensions of the network-on-chip to obtain the target performance parameters of the network-on-chip, including: obtaining the expected performance parameters, the performance parameter dataset, and the attribute information of the network-on-chip. Among them, the expected performance parameters include one or more of the expected delay parameter, the expected bandwidth parameter, and the expected number parameter of unresponded transactions. The performance parameter dataset includes one or more of the delay dataset, the bandwidth dataset, and the unresponded transaction dataset; using the expected performance parameters, the performance parameter dataset, and the attribute information of the network-on-chip, the performance parameters of the network-on-chip are adjusted multiple times until a preset condition is met. The preset condition includes at least one of the following: the performance parameters of the network-on-chip reach the expected performance parameters, and the total number of multiple adjustments reaches the regression number.

[0099] The bandwidth analysis tool in the debugging platform can analyze the bandwidth of the network-on-chip, the delay analysis tool can analyze the delay of the network-on-chip, and the outstanding analysis tool can analyze the outstanding on the network-on-chip.

[0100] The bandwidth analysis tool can generate the expected bandwidth parameters and attribute information according to the architecture definition information. Among them, the attribute information includes the vendor information and version information of the NoC. The bandwidth analysis tool can also collect the bandwidth data of the components and network paths specified by the user according to the user's specification and generate a bandwidth dataset. For example, as Figure 6 shown, when selecting components or network paths, the user selects the network path for Initiator A to access Target C. When selecting the display time range, the user selects the start time as T1 and the end time as T2. Among them, the components include one or more of the host, the slave, and the NoC, and the network path is the path between each host and each accessible slave. The bandwidth analysis tool can automatically adjust the parameters controlling the bandwidth according to the expected bandwidth parameters, the bandwidth dataset, and the attribute information until the bandwidth parameters of the NoC meet the expected bandwidth parameters or the number of adjustments reaches the set regression number. In the bandwidth analysis tool, when the number of adjustments reaches the set regression number, the automatic adjustment of the parameters controlling the bandwidth is stopped, so as to avoid that due to the unreasonable setting of the expected bandwidth parameters, the bandwidth parameters of the network-on-chip can never reach the set expected bandwidth parameters, resulting in the bandwidth analysis tool entering an infinite loop.

[0101] After the bandwidth analysis tool runs to completion, the user can according to Figure 6The user interface shown selects components or network paths and selects the display time range. For the on-chip networks corresponding to Initiator (the initiator of the transaction) A, Initiator B, Target (the recipient of the transaction) A, Target B, and Target C, Figure 6 The user interface when the network path for Initiator A to access Target C is selected is shown.

[0102] Table 1

[0103]

[0104] After the user selects a component or path on the user interface, the detailed information of each component will be displayed in the form of graphs and tables on the user interface for the user's reference. As Figure 7 shown, the average bandwidth utilization of the network path for Initiator A to access Target C between time T1 and time T2 is shown, where the simulation time is t1 ns, the average bandwidth utilization is 90%, and the sampling interval is 100 ns. At the same time, under the current bandwidth utilization, the performance parameters of the NoC are also displayed in tabular form on the user interface. As shown in Table 1, in the case of an average bandwidth utilization of 62.5%, between time T1 and time T2, the performance parameters of Initiator A accessing Target C and the performance parameters of the NoC, where pending_transfer is used to represent a pending transfer, which refers to a transfer transaction that has been initiated but not yet completed. For example, after Initiator A sends a request to Target C, before the data is successfully transmitted and confirmed, the transfer process is in the pending_transfer state; pending_id is used to represent the identifier associated with the pending transfer transaction (pending_transfer); id_compress_algorithm is used to represent the identifier compression algorithm; early_response is for early response, which is a mechanism or behavior that allows Target C to send a response to Initiator A in advance before completing the entire processing of Initiator A's request after receiving Initiator A's request. The purpose of this mechanism is usually to improve the performance and response speed of the system, enabling Initiator A to learn about the partial status or results of the request faster without having to wait for the slave device to complete all processing before obtaining feedback. It should be understood that the bold font in Table 1 is the performance parameters of the selected component by the user and the performance parameters of the NOC.

[0105] The delay analysis tool can generate expected delay parameters and attribute information based on the architecture definition information, and can also collect the delay data of the components and network paths specified by the user according to the user's specification to generate a delay data set. For example, as Figure 8 shown, when selecting components or network paths, it is used to select InitiatorA to access TargetC, and also select InitiatorB to access TargetB; when selecting the display time range, it is used to select the start time as T1 and the end time as T2. The delay analysis tool can automatically adjust the parameters controlling the delay according to the expected delay parameters, the delay data set and the attribute information until the delay parameters of the NoC meet the expected delay parameters or the number of adjustment times reaches the set regression times. In the delay analysis tool, when the number of adjustment times reaches the set regression times, the automatic adjustment of the parameters controlling the delay is stopped, so as to avoid that due to the unreasonable setting of the expected delay parameters, the delay parameters of the on-chip network can never reach the set expected delay parameters, resulting in the delay analysis tool entering an infinite loop.

[0106] Table II

[0107]

[0108] After the delay analysis tool runs to completion, the user can, according to Figure 8 the user interface shown, select the components or network paths to be displayed on the user interface, and select the display time range. Figure 8 Shows the interface when the network paths of Initiator A accessing TargetC and Initiator B accessing Target B are selected.

[0109] After the user selects components or network paths on the user interface, the detailed information of each component will be displayed in the form of graphs and tables on the user interface for the user's reference. As Figure 9As shown, it presents the average latency of InitiatorA accessing Target C and Initiator B accessing Target B between time T1 and time T2, where the simulation time is t1 ns, the average latency is d1 ns, and the sampling interval is 100 ns. Under the current latency results, the values of the performance parameters of the NoC will also be presented. Table II presents the performance parameters of the NoC when Initiator A accesses Target C and Initiator B accesses Target B between time T1 and time T2. Table III presents the average latency when Initiator A accesses TargetC and Initiator B accesses Target B between time T1 and time T2. It should be understood that the bold fonts in Table II and Table III are the performance parameters of the components selected by the user and the performance parameters of the NOC.

[0110] Table III

[0111]

[0112] Table IV

[0113]

[0114] The outstanding analysis tool can generate the expected outstanding number parameter (i.e., the expected number parameter of unresponded transactions) and attribute information according to the architecture definition information. The outstanding analysis tool can also collect the latency data of the components and network paths specified by the user according to the user's specification, and generate an outstanding number data set, that is, an unresponded transaction data set. For example, as Figure 10As shown, when selecting components or network paths, Initiator A and Target C are selected. When selecting the display time range, the user selects the start time as T1 and the end time as T2. The outstanding analysis tool can automatically adjust the outstanding count parameter according to the expected outstanding count parameter, the outstanding count data set, and the attribute information until the outstanding count parameter of the NoC meets the expected outstanding count parameter or the number of adjustment times reaches the set regression times. In the outstanding analysis tool, when the number of adjustment times reaches the set regression times, the automatic adjustment of the outstanding count parameter is stopped. This is to avoid the situation where due to the unreasonable setting of the expected outstanding count parameter, the outstanding count parameter of the on-chip network can never reach the set expected outstanding count parameter, resulting in the delay analysis tool entering an infinite loop. After the outstanding analysis tool finishes running, the user can, according to Figure 10 the user interface shown, select the components or network paths to be displayed on the user interface, and select the display time range. As Figure 10 shown, Initiator A and Target C are selected. After the user selects the components or network paths on the user interface, the detailed information of each component will be displayed in the form of graphs and tables on the user interface for the user's reference. As Figure 11 shown, the outstanding count parameter of Initiator A and Target C between time T1 and time T2. Under the current outstanding result, the value of the performance parameter of the NoC will also be displayed. As shown in Table IV, the outstanding count parameter of Initiator A and Target C and the performance parameter of the NoC between time T1 and time T2 are displayed. It should be understood that the bold font in Table IV is the performance parameter of the component selected by the user and the performance parameter of the NoC.

[0115] Using the expected performance parameter of the on-chip network, the performance parameter data set, and the attribute information, the performance parameter of the on-chip network can be automatically adjusted so that the performance parameter of the on-chip network can quickly reach the expected performance parameter.

[0116] From the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0117] For ease of understanding, asFigure 12 As shown in the figure, the embodiment of the present application further provides a schematic flowchart of another method for debugging a system on a chip, which specifically includes steps S1201 to S1215.

[0118] Step S1201, extract architecture definition information. Using this architecture definition information, a test platform and a debugging platform can be generated. Among them, the test platform debugs the network on the chip through test cases and generates a log file and a signal waveform file.

[0119] Step S1202, the debugging platform can obtain the log file and the signal waveform file from the test platform.

[0120] Step S1203, determine whether to perform function verification or performance debugging. In the case of performing function verification, execute steps S1204 to S1212; in the case of performing performance debugging, execute steps S1213 to S1215.

[0121] Step S1204, use a protocol analysis tool to check the communication protocol corresponding to the transaction initiated by the host and the communication protocol corresponding to the transaction responded by the slave.

[0122] Step S1205, determine whether the communication protocol is violated. In the case of violating the communication protocol, execute step S1211; in the case of not violating the communication protocol, execute steps S1206 to S1212.

[0123] Step S1206, use an address range analysis tool to check whether the address of the transaction initiated by the host is within the Initiator address range corresponding to the slave to be accessed, and whether the address received by the slave after being transmitted through the NoC is within the Target address range corresponding to the slave.

[0124] Step S1207, determine whether the communication address is correct. In the case of an incorrect communication address, execute step S1211; in the case of a correct communication address, execute steps S1208 to S1212.

[0125] Step S1208, use a slave status check tool to detect the working status of the slave.

[0126] Step S1209, determine whether the slave is in a workable state. In the case of not being in a workable state, execute step S1211; in the case of being in a workable state, execute steps S1210 to S1212.

[0127] Step S1210, use a waveform comparison analysis tool to determine whether a waveform error occurs. In the case of a waveform error occurring, execute steps S1211 and S1212.

[0128] Step S1211, correct the test case.

[0129] Step S1212, correct the DUT (the DUT is the network on chip).

[0130] Step S1213, use the bandwidth analysis tool to automatically adjust the parameters for controlling the bandwidth according to the expected bandwidth parameters, bandwidth data sets, and attribute information, and obtain the graphs and tables related to the bandwidth utilization rate of the component.

[0131] Step S1214, use the delay analysis tool to automatically adjust the parameters for controlling the delay according to the expected delay parameters, delay data sets, and attribute information, and obtain the graphs and tables related to the average delay of the component.

[0132] Step S1215, use the outstanding analysis tool to automatically adjust the parameters for controlling the outstanding according to the expected outstanding parameters, outstanding number data sets, and attribute information, and obtain the graphs and tables related to the number of outstanding of the component.

[0133] The debugging platform proposed in the embodiment of the present application can automatically detect problems, correct errors or provide correction solutions, thereby helping users quickly and efficiently complete the function debugging and performance analysis of the network on chip. Secondly, the function debugging module includes a protocol analysis tool, an address range analysis tool, a slave status check tool, and a waveform comparison analysis tool. These four sub-tools can help users solve the problems encountered in the debugging of the network on chip verification process. Finally, the performance debugging module includes a bandwidth analysis tool, a delay analysis tool, and an outstanding analysis tool. These three tools provide the performance parameters of the network on chip that users are concerned about. Moreover, the performance debugging module can automatically adjust the parameters for controlling the DUT according to the expected performance indicators, the NoC manufacturer information and version information used, so that the performance results can meet the expected performance indicators as much as possible. The debugging method of the network on chip in the present application is implemented in the form of a script, which has extremely high reusability and can be applied throughout the network on chip verification process, accelerating the efficiency of function verification and performance debugging.

[0134] The embodiment of the present application also provides a debugging device for a network on chip. For the description of the features corresponding to the embodiment of the debugging device for the network on chip, reference can be made to the relevant description of the corresponding embodiment of the debugging method for the network on chip, which will not be elaborated here one by one. As Figure 13 shown, the debugging device for the network on chip includes:

[0135] The first acquisition module 1310 is configured to acquire a log file and a signal waveform file, where the log file and the signal waveform file are generated during the process of the test platform debugging the network-on-chip through test cases.

[0136] The function verification module 1320 is configured to perform function verification on multiple function dimensions of the network-on-chip based on the data corresponding to the log file and the signal waveform file, and obtain function verification results under each function dimension.

[0137] The performance debugging module 1330 is configured to perform performance debugging on multiple performance dimensions of the network-on-chip based on the data corresponding to the log file and the signal waveform file, and obtain the target performance parameters of the network-on-chip.

[0138] The debugging result generation module 1340 is configured to fuse the function verification results and / or the target performance parameters to generate a network debugging result.

[0139] In some alternative embodiments, the function verification module further includes a first determination sub-module, a second determination sub-module, and a first generation sub-module. Among them, the first determination sub-module is configured to determine a target signal corresponding to the error time from the signal waveform file based on the error information corresponding to the error time in the log file; the second determination sub-module is configured to determine whether the target signal violates the communication protocol; the first generation sub-module is configured to check and correct the test case when the target signal violates the communication protocol, and generate a function verification result.

[0140] In some alternative embodiments, the debugging device of the network-on-chip further includes a second acquisition module, a first determination module, and a first generation module. Among them, the second acquisition module is configured to acquire an address mapping table when the target signal does not violate the communication protocol; the first determination module is configured to determine whether the communication address between the host and the slave is correct based on the address mapping table, the communication protocol of the host and the received error type, and the communication protocol of the slave and the received error type; the generation module is configured to check and correct the test case when the communication address between the host and the slave is incorrect, and generate a function verification result.

[0141] In some alternative embodiments, the debugging device of the network-on-chip further includes a second determination module, a configuration module, a third acquisition module, a fourth acquisition module, a comparison module, and a second generation module. Among them, the second determination module is configured to determine whether the slave is in a workable state based on the start time of the transaction initiated by the master obtained from the log file and / or the type of error response fed back by the network interface unit of the slave when the communication address between the master and the slave is correct; the configuration module is configured to, when the slave is not in a workable state, check and correct the test case, generate a functional verification result, and configure the slave based on the slave preset file to make the slave in a workable state, and the slave preset file is used to define the conditions for the slave to be in a workable state; the third acquisition module, when the slave is in a workable state, acquires a comparison control file corresponding to the test case, and the comparison control file is used to define each network node for test case checking and the priority of each network node, and each network node is a network node of the network-on-chip; the fourth acquisition module acquires the signal waveforms of each network node from the signal waveform file; the comparison module is configured to compare the signal waveforms of each network node with the corresponding reference waveforms according to the priorities of each network node in the comparison control file; the second generation module is configured to, when there is one or more network nodes whose signal waveforms are inconsistent with the corresponding reference waveforms, check and correct the test case, generate a functional verification result, and adjust the configuration parameters of the test platform and the configuration parameters of the network-on-chip.

[0142] In some alternative embodiments, the first determination module includes a third determination sub-module, a fourth determination sub-module, a fifth determination sub-module, and a sixth determination sub-module. Among them, the third determination sub-module is configured to determine whether the address corresponding to the transaction initiated by the host is correct based on the address corresponding to the transaction initiated by the host and the address mapping table when the network interface unit of the host receives a decoding error response and the communication protocol of the host is the first communication protocol or the second communication protocol; the fourth determination sub-module is configured to determine that the address corresponding to the transaction initiated by the host is incorrect if the address corresponding to the transaction initiated by the host is within the slave reserved address range when the network interface unit of the host receives a slave error response, the communication protocol of the host is the first communication protocol or the second communication protocol, the communication protocol of the slave is the third communication protocol or the fourth communication protocol, and the network interface unit of the slave feeds back the slave error response, and the slave reserved address range is generated based on the address mapping table; the fifth determination sub-module is configured to determine that the address corresponding to the transaction initiated by the host is incorrect when the network receiving unit of the host receives a slave error response, the communication protocol of the host is the third communication protocol or the fourth communication protocol, the communication protocol of the slave is the first communication protocol, and the network interface unit of the slave feeds back a decoding error response; the sixth determination sub-module is configured to determine that the address corresponding to the transaction initiated by the host is incorrect if the address corresponding to the transaction initiated by the host is within the slave reserved address range when the network interface unit of the host receives a slave error response, the communication protocol of the host is the third communication protocol or the fourth communication protocol, the communication protocol of the slave is the third communication protocol or the fourth communication protocol, and the network interface unit of the slave feeds back the slave error response.

[0143] In some alternative embodiments, the second determination module includes a first acquisition sub-module, a second acquisition sub-module, and a fifth determination sub-module, or the second determination module includes a sixth determination sub-module and a seventh determination sub-module. Among them, the first acquisition sub-module is configured to acquire a time window threshold value; the second acquisition sub-module is configured to acquire the start time of the transaction initiated by the host from the log file; the fifth determination sub-module is configured to determine that the slave is not in a workable state if the slave does not respond to the transaction initiated by the host after a time window threshold value has elapsed since the start time. Alternatively, the sixth determination sub-module is configured to determine that the slave is not in a workable state when the communication protocol of the slave is the first communication protocol and the network interface unit of the slave feeds back a slave error response; the seventh determination sub-module is configured to determine that the slave is not in a workable state when the communication protocol of the slave is the third communication protocol or the fourth communication protocol and the network interface unit of the slave feeds back a slave error response.

[0144] In some alternative embodiments, the performance debugging module includes a third acquisition sub-module and an adjustment sub-module. The third acquisition sub-module is configured to acquire the expected performance parameters, the performance parameter data set, and the attribute information of the on-chip network. The expected performance parameters include one or more of the expected latency parameter, the expected bandwidth parameter, and the expected number parameter of unresponsive transactions. The performance parameter data set includes one or more of the latency data set, the bandwidth data set, and the unresponsive transaction data set. The adjustment sub-module is configured to use the expected performance parameters, the performance parameter data set, and the attribute information of the on-chip network to adjust the performance parameters of the on-chip network multiple times until a preset condition is met. The preset condition includes at least one of the following: the performance parameters of the on-chip network reach the expected performance parameters, and the total number of multiple adjustments reaches the regression number.

[0145] In the debugging device of the on-chip network provided by the embodiment of the present application, the test platform generates a log file and a signal waveform file during the process of debugging the on-chip network through test cases. The debugging platform acquires the log file and the signal waveform file. Based on the data corresponding to the acquired log file and signal waveform file, the on-chip network can be functionally verified in multiple functional dimensions to obtain the functional verification results in each functional dimension, and the on-chip network can be performance-verified in multiple performance dimensions to obtain the target performance parameters of the on-chip network. Finally, by fusing the functional verification results and / or the target performance parameters, the network debugging result is obtained. This solution can automatically perform functional verification and performance debugging on the on-chip network only through the log file and the signal waveform file, find the reasons for functional errors and performance non-compliance, without acquiring much other information. Therefore, it can help users quickly and efficiently complete the functional debugging and performance analysis of the on-chip network, thereby improving the verification efficiency of verifying the on-chip network and shortening the verification cycle, and further solving the problem of low efficiency in functional debugging and performance analysis of the on-chip network in the related art.

[0146] An embodiment of the present application further provides an electronic device, such as Figure 14 shown, including a memory 1410 and a processor 1420. A computer program is stored in the memory 1410, and the processor 1420 is configured to run the computer program to execute the steps in any of the above embodiments of the debugging method for the on-chip network.

[0147] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps in any of the above embodiments of the debugging method for the on-chip network when running.

[0148] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to: various media that can store computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), mobile hard disks, magnetic disks, or optical discs.

[0149] The embodiments of the present application also provide a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the steps in any of the above-described embodiments of the on-chip network debugging method are implemented.

[0150] The embodiments of the present application also provide another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-described embodiments of the on-chip network debugging method are implemented.

[0151] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Skilled professionals can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0152] The above has introduced in detail a method, device, electronic device, and readable storage medium for debugging an on-chip network provided by the present application. Specific examples are used in this article to elaborate on the principle and implementation manner of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A method for debugging a network on chip, characterized in that: include: Acquire a log file and a signal waveform file, wherein the log file and the signal waveform file are generated by the test platform during the process of debugging the on-chip network through the test case; Based on the data corresponding to the log file and the signal waveform file, functional verification is performed on multiple functional dimensions of the on-chip network to obtain functional verification results under each of the functional dimensions; Based on the data corresponding to the log file and the signal waveform file, performance debugging is performed on multiple performance dimensions of the network on chip to obtain target performance parameters of the network on chip; The function verification result and / or the target performance parameter are integrated to generate a network debugging result.

2. The method according to claim 1, characterized in that Based on the data corresponding to the log file and the signal waveform file, functional verification is performed on multiple functional dimensions of the on-chip network to obtain functional verification results under each of the functional dimensions, including: Based on the error information corresponding to the error time in the log file, determining the target signal corresponding to the error time from the signal waveform file; determining whether the target signal violates a communication protocol; In the case where the target signal violates the communication protocol, the test case is checked and corrected to generate the functional verification result.

3. The method according to claim 2, characterized in that The method further comprises: When the target signal does not violate the communication protocol, obtaining an address mapping table; Determining whether the communication address between the host and the slave is correct based on the address mapping table, the communication protocol of the host and the received error type, and the communication protocol of the slave and the received error type; In the case where the communication address between the host and the slave is incorrect, the test case is checked and corrected to generate the function verification result.

4. The method according to claim 3, characterized in that The method further comprises: In the case that the communication address between the host and the slave is correct, determining whether the slave is in an operable state based on the start time of the transaction initiated by the host obtained from the log file and / or the type of the error response fed back by the network interface unit of the slave; In the case that the slave is not in an operable state, checking and correcting the test case, generating the function verification result and configuring the slave based on a slave preset file so that the slave is in an operable state, wherein the slave preset file is used to define a condition for the slave to be in an operable state; When the slave is in an operable state, obtaining a comparison control file corresponding to the test case, wherein the comparison control file is used to define each network node checked by the test case and a priority of each network node, each network node being a network node of the on-chip network; Acquire the signal waveform of each of the network nodes from the signal waveform file; According to the priority of each of the network nodes in the comparison control file, comparing the signal waveform of each of the network nodes with the corresponding reference waveform; In the event that the signal waveform of one or more of the network nodes is inconsistent with the corresponding reference waveform, the test case is checked and corrected, the functional verification result is generated, and the configuration parameters of the test platform and the configuration parameters of the on-chip network are adjusted.

5. The method according to claim 3, characterized in that: Determining whether the communication address between the host and the slave is correct based on the address mapping table, the communication protocol of the host and the received error type, and the communication protocol of the slave and the received error type, includes: When the network interface unit of the host receives a decoding error response and the communication protocol of the host is the first communication protocol or the second communication protocol, determining whether the address corresponding to the transaction initiated by the host is correct based on the address corresponding to the transaction initiated by the host and the address mapping table; In a case where the network interface unit of the host receives an error response from a slave, the communication protocol of the host is the first communication protocol or the second communication protocol, the communication protocol of the slave is the third communication protocol or the fourth communication protocol, and the network interface unit of the slave feeds back the slave error response, if the address corresponding to the transaction initiated by the host is within a reserved address range for the slave, it is determined that the address corresponding to the transaction initiated by the host is incorrect, and the reserved address range for the slave is generated based on the address mapping table; In the case where the network receiving unit of the host receives the error response of the slave, the communication protocol of the host is the third communication protocol or the fourth communication protocol, the communication protocol of the slave is the first communication protocol, and the network interface unit of the slave feeds back the decoding error response, determining that the address corresponding to the transaction initiated by the host is incorrect; When the network interface unit of the host receives an error response from the slave, the communication protocol of the host is the third communication protocol or the fourth communication protocol, the communication protocol of the slave is the third communication protocol or the fourth communication protocol, and the network interface unit of the slave feeds back the slave error response, if the address corresponding to the transaction initiated by the host is within the reserved address range of the slave, it is determined that the address corresponding to the transaction initiated by the host is incorrect.

6. The method according to claim 4, characterized in that Determining whether the slave is in an operable state based on the start time of the transaction initiated by the host and / or the type of the error response fed back by the network interface unit of the slave obtained from the log file includes: Get the time window threshold value; Obtaining the start time of the transaction initiated by the host from the log file; Starting from the start time, after the time window threshold has passed, if the slave does not respond to the transaction initiated by the host, determining that the slave is not in an operable state; and / or, When the communication protocol of the slave is the first communication protocol and the network interface unit of the slave feeds back a slave error response, determining that the slave is not in an operable state; When the communication protocol of the slave is the third communication protocol or the fourth communication protocol, and the network interface unit of the slave feeds back an error response of the slave, it is determined that the slave is not in an operable state.

7. The method according to claim 1, characterized in that Based on the data corresponding to the log file and the signal waveform file, multiple performance dimensions of the network on chip are debugged to obtain target performance parameters of the network on chip, including: Acquire expected performance parameters, performance parameter data sets, and attribute information of the network on chip, wherein the expected performance parameters include one or more of expected delay parameters, expected bandwidth parameters, and expected number of unresponded transactions, and the performance parameter data sets include one or more of delay data sets, bandwidth data sets, and unresponded transaction data sets; Using the expected performance parameters of the on-chip network, the performance parameter data set and the attribute information, the performance parameters of the on-chip network are adjusted multiple times until preset conditions are met, and the preset conditions include at least one of the following: the performance parameters of the on-chip network reach the expected performance parameters, and the total number of multiple adjustments reaches the regression number.

8. A debugging device for a network on chip, characterized in that: include: A first acquisition module is used to acquire a log file and a signal waveform file, wherein the log file and the signal waveform file are generated by the test platform during the process of debugging the on-chip network through the test case; A function verification module, used to perform function verification on multiple function dimensions of the network on chip based on the data corresponding to the log file and the signal waveform file, and obtain function verification results under each function dimension; A performance debugging module, used to perform performance debugging on multiple performance dimensions of the network on chip based on the data corresponding to the log file and the signal waveform file, and obtain target performance parameters of the network on chip; The debugging result generating module is used to fuse the function verification result and / or the target performance parameter to generate a network debugging result.

9. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the on-chip network debugging method as claimed in any one of claims 1 to 7 when executing a computer program.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the debugging method for the network on chip according to any one of claims 1 to 7.

Images