A software and hardware collaborative monitoring method and device for on-chip network protocol

Abstract

This invention discloses a hardware-software collaborative monitoring method and apparatus for on-chip network protocols. The method includes providing function bodies for shared use in the software portion through a shared function body declaration component in the synthesizable hardware portion; firstly, the non-synthesizable software portion instantiates the function bodies provided by the shared function body declaration component to capture CHI messages from various channels of the on-chip network protocol in the SoC under test; then, the CHI messages are output directly without verification, or the monitoring results are output after decoding, encoding, and specified protocol analysis of the CHI messages. This invention is applicable to FPGA prototyping platforms, has low hardware resource consumption, low system cost, and is quick and simple to implement. It enables efficient monitoring and analysis of CHI protocol messages on the prototyping platform, effectively accelerating the localization and performance analysis of SoC problems and improving SoC design efficiency.

Description

Technical Field

[0001] This invention belongs to the field of silicon pre-verification in the field of integrated circuits, and specifically relates to a software and hardware co-monitoring method and device for on-chip network protocols. Background Technology

[0002] Verification of SoC (System on Chip) is an extremely complex task throughout the entire chip design and market launch process. The time and effort invested in SoC verification can account for 60% or more of the entire system development and design time. Only with sufficient verification results in the pre-silicon verification stage can engineers confidently proceed with tape-out. However, in the system-level verification stage, engineers have limited efficient verification methods for chip functionality and performance. For functional verification, debugging methods such as waveform capture are generally used to find faults, making it difficult to pinpoint the specific faulty module within the SoC. Locating a single problem can take a month or even several months, significantly impacting production efficiency. In performance verification, when SoC performance fails to meet expected design specifications, engineers struggle to pinpoint specific performance bottlenecks based on overall system performance data. Therefore, how to efficiently and accurately verify the functionality and performance of large SoC systems during SoC development is a pressing problem. Based on this situation, researchers have started with bus protocols, analyzing the on-chip network protocols of the SoC to obtain more internal chip state information, improving chip observability, and thus enabling efficient problem localization, analysis, and handling. The CHI protocol is a widely adopted on-chip protocol specification, comprising a protocol layer, a network layer, and a link layer. The protocol layer is the top layer of the entire architecture, based on transactions, managing transaction flows and node cache state transitions. The network layer is responsible for packet routing, determining the destination node, source node, and other information, and adding it to the data packets to ensure that the packets can be routed to their destination during interconnection. The link layer, using data slices as the basic unit, implements six link channels at the hardware level: request channel, output data channel, output feedback channel, input feedback channel, input data channel, and listen channel, offering advantages such as high bandwidth and high concurrency. The operation of the CHI protocol provides insight into the operational status of multiple components interconnected through the on-chip network.

[0003] To enhance engineers' understanding of on-chip interconnects, a high-efficiency monitor based on on-chip network protocols is needed for monitoring these protocols. Currently, many companies have developed VIPs for monitoring on-chip network protocols such as AXI and CHI. However, these tools are implemented in either fully synthesizable or fully non-synthesizable forms. The fully non-synthesizable implementation is module-oriented and not suitable for system-level verification on FPGA prototyping platforms. The fully synthesizable implementation consumes a large amount of hardware resources on the FPGA prototyping platform in practical use. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide a hardware and software co-monitoring method and device for on-chip network protocols, which addresses the above-mentioned problems in the prior art. This invention can achieve efficient monitoring of on-chip network protocols. On the FPGA platform, through a synthesizable and non-synthesizable two-part structure, a system-level verification method suitable for FPGA prototyping platforms is realized, which has low hardware resource consumption, low system cost, and quick and simple verification method. It can realize the monitoring and analysis of CHI protocol messages on the prototyping platform, effectively accelerate the localization of SoC problems and performance analysis, and improve SoC design efficiency.

[0005] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0006] A hardware-software co-monitoring method for on-chip network protocols includes providing function bodies for shared use in the software part through a shared function body declaration component in the synthesizable hardware part; firstly, instantiating the function bodies provided by the shared function body declaration component through the non-synthesizable software part to capture CHI messages in the SoC under test from various channels of the on-chip network protocol; then directly outputting the CHI messages without verification, or decoding, assembling, and performing specified protocol analysis on the CHI messages before outputting the monitoring results.

[0007] It also includes a storage parameter configuration component provided through synthesizable hardware to set data storage configuration information for use by non-synthesizable software. The data storage configuration information includes the output location of data files and log files (LOG), the location of data packet parameter configuration files, and the node number of the SoC under test.

[0008] It also includes a monitoring status control component provided through a synthesizable hardware component, which can be used to set the enable signal low to stop the output transmission of CHI messages or monitoring results when there is no monitoring requirement, and set the enable signal high to resume the output transmission of CHI messages or monitoring results when there is a monitoring requirement.

[0009] A hardware-software co-monitoring device using the aforementioned on-chip network protocol co-monitoring method includes an interconnected DPI-C interface and an on-chip network protocol monitor, wherein the on-chip network protocol monitor includes:

[0010] The data transmission module is used to provide function bodies for shared use by the software part through the shared function body declaration component in the synthesizable hardware part; the non-synthesizable software part first instantiates the function bodies provided by the shared function body declaration component to capture CHI messages in the SoC under test from various channels through the on-chip network protocol;

[0011] The data fragment decoding and encoding module is used to decode and encode CHI messages;

[0012] The protocol analysis model module is used to perform specified protocol analysis processing on the grouped data packets.

[0013] The data transmission module is connected to the CHI protocol signal in the SoC under test via a binding method. The data transmission module, the data chip decoding and coding module, and the protocol analysis model module are connected in sequence. The data chip decoding and coding module and the protocol analysis model module are non-synthesizable software parts.

[0014] The shared function body declaration component in the data transmission module declares function bodies shared by the hardware and software parts in the synthesizable hardware part through import.

[0015] The non-synthesizable software components of the data transmission module include: a data slice parameter configuration module, used to set the field format of CHI bus protocol data slices to support different CHI protocols, and to read configurable parameter fields of the CHI protocol using parameter input methods, specifically including address bit width, data bit width, node number bit width, transaction number bit width, and custom bit width; a monitor data management module, used to instantiate shared function bodies, and to implement data transmission of the master request channel, slave data channel, slave feedback channel, slave listening channel, master feedback channel, and master data channel, with different data identified by a unique handle index in the handle list; and a monitor mode control module, used to select offline mode and online mode through macro definition. In offline mode, CHI messages are output directly without verification, while in online mode, CHI messages are decoded, grouped, and analyzed according to specified protocols before the monitoring results are output.

[0016] The monitor mode control module outputs CHI messages directly without verification in offline mode, including: Step 1, when the on-chip network protocol monitor enable signal is high, the monitoring clock starts counting, a data file DAT is created according to the data file output position in the storage parameter configuration component, and the handle of the data file DAT is saved in the handle list in the monitor data management module; Step 2, when the valid signal in the monitored channel is high, the complete information of the data chip in the channel, the monitoring clock count, and the channel type are transmitted to the workstation through a shared function body, the data file handle is searched in the handle list according to the node number in the storage parameter configuration component, and the data is output in the data file DAT; Step 3, when the on-chip network protocol monitor enable signal is low, the data file DAT is closed; The monitor mode control module decodes CHI messages in online mode, After analyzing and processing the group code and the specified protocol, the monitoring results are output as follows: Step 1, when the on-chip network protocol monitor enable signal is high, the monitoring clock starts counting. According to the log file LOG output position in the storage parameter configuration component, a log file LOG is created, and the log file LOG handle is saved in the handle list in the monitor data management module 15; Step 2, when the valid signal in the monitored channel is pulled high, the complete information of the data segment in the channel, the monitoring clock count, and the channel type are transmitted to the workstation through the shared function body. The data segment decoding group code module and the protocol analysis model module complete the protocol monitoring online. According to the node number in the storage parameter configuration component, the log file LOG handle is searched in the handle list, and the monitoring results are output in the log file LOG; Step 3, when the on-chip network protocol monitor enable signal is low, the log file LOG is turned off.

[0017] The data fragment decoding and coding module includes: a decoding module, used to operate on data packets, and according to the data fragment field format passed from the data packet parameter configuration module in the data transmission module, decodes the messages in the six channels of the CHI protocol—main request channel, slave data channel, slave feedback channel, slave listening channel, main feedback channel, and main data channel—according to the CHI protocol specification, decomposing the complete data fragment into various field information based on the bit width through shift and AND / OR operations, and storing the decoded field information in the data fragment structure; and a coding module, used to parse the data in the data fragment structure into transaction flow control variables; the transaction flow control variables specifically include whether the message is a no-data-type message, a listenable type message, an atomic type message, a cached state setting related message, or a DVM type message, as mapped according to the opcode field, and whether a feedback message is needed, as mapped according to whether feedback confirmation is required; the decoding module and the coding module are interconnected, the decoding module is connected to the output of the data transmission module, and the output of the coding module is used to output the coded data packets, and simultaneously uses the coded data packets as input to the protocol analysis model module.

[0018] The protocol analysis model module includes:

[0019] The transaction flow tracing module converts the data sent by the data slice decoding and encoding module into transaction flow data with a transaction flow order as the storage structure. The transaction flow data packets are stored using two types of transaction flow structures: request and listener. Each transaction flow structure includes a request or listener message, a set of data packets, a feedback message, a transaction flow count, transaction flow operation parsing variables, and a structure initialization function. The transaction flow count is used to mark the progress of the transaction lifecycle; each detected packet decrements the transaction flow count by one, and the transaction flow lifecycle ends when the count reaches zero. The transaction flow operation parsing variables are used to determine the type of subsequent packets in the transaction flow, including: whether it is a packet with no data type, a listenable type, an atomic type, a cached state setting related packet, and a DVM type packet. The structure initialization function initializes all transaction flow operation parsing variables, the initial value of the transaction count, and the packets.

[0020] The link layer verification module is used to verify the correctness of six types of channel link layer data, including channel credit count verification and message link layer field verification.

[0021] The protocol layer verification module is used to verify the correctness of six channel protocol layer transaction flows, and to perform detailed transaction flow analysis and conflict monitoring.

[0022] The problem feedback module is used to control the subsequent operations of the monitor when it detects a fatal error. When the link layer input module and the protocol layer verification module detect a problem, they actively report the error and output the complete information of the transaction flow where the problem occurred and the basic error message in the monitoring log. Depending on the monitor settings, the simulation can be stopped or continued.

[0023] The transaction flow tracing module, the link layer verification module, and the protocol layer verification module are connected in sequence, and the link layer verification module and the protocol layer verification module are respectively connected to the problem feedback module.

[0024] The protocol analysis model module also includes a coverage monitoring module, which monitors all messages in the data packet by channel. Each channel contains a message type count table to record the number of times each message type occurs. When a message is detected, the count of the transaction type corresponding to the current message opcode field is incremented by one. When the monitoring is completed, the number of occurrences of all message types and the coverage of message types in each channel are statistically output to the log file LOG.

[0025] Compared with existing technologies, the present invention has the following main advantages: The present invention includes providing function bodies for shared use in the software part through a shared function body declaration component in a synthesizable hardware part; the non-synthesizable software part first instantiates the function bodies provided by the shared function body declaration component to capture CHI messages in the SoC under test from various channels of the on-chip network protocol, and then outputs the CHI messages directly without verification, or decodes, groups, and performs specified protocol analysis on the CHI messages before outputting the monitoring results. The present invention implements a system-level verification method suitable for FPGA prototyping platforms with small hardware resource consumption, low system cost, and fast and simple verification method through a synthesizable and non-synthesizable two-part structure on the FPGA platform. It can realize efficient monitoring and analysis of CHI protocol messages on the prototyping platform, effectively accelerate the localization and performance analysis of SoC problems, and improve SoC design efficiency. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the basic process of the method in an embodiment of the present invention.

[0027] Figure 2 This is a schematic diagram of the monitoring device according to an embodiment of the present invention.

[0028] Figure 3 This is a schematic diagram of the data transmission module in the monitor of this embodiment of the invention.

[0029] Figure 4 This is a schematic diagram of the binary file format in the monitor of an embodiment of the present invention.

[0030] Figure 5 This is a schematic diagram of the protocol analysis model module in the monitor of this embodiment of the invention.

[0031] Legend: 1. Data transmission module; 11. Storage parameter configuration component; 12. Shared function body declaration component; 13. Hardware part provides monitoring status control component; 14. Parameter configuration module; 15. Monitor data management module; 16. Monitor mode control module; 2. Data slice decoding and encoding module; 3. Protocol analysis model module; 31. Transaction flow tracing module; 32. Link layer verification module; 33. Protocol layer verification module; 34. Problem feedback module; 35. Coverage monitoring module. Detailed Implementation

[0032] To make the technical problems solved, the technical solutions, and the beneficial effects of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0033] like Figure 1 As shown, the hardware and software co-monitoring method for on-chip network protocol in this embodiment includes providing a function body for shared use by the software part through the shared function body declaration component 12 in the synthesizable hardware part; the non-synthesizable software part first instantiates the function body provided by the shared function body declaration component 12 to capture CHI messages in the SoC under test from various channels of the on-chip network protocol, and then outputs the CHI messages directly without verification, or decodes, groups, and performs specified protocol analysis on the CHI messages before outputting the monitoring results.

[0034] In addition, the hardware and software co-monitoring method for on-chip network protocols in this embodiment also includes a storage parameter configuration component 11 provided by a synthesizable hardware part for setting data storage configuration information for use by a non-synthesizable software part. The data storage configuration information includes the output location of data files and log files (LOG), the location of data packet parameter configuration files, and the node number of the SoC under test.

[0035] In addition, the hardware and software collaborative monitoring method of the on-chip network protocol in this embodiment also includes a monitoring status control component 13 provided by a synthesizable hardware part, which is used to set the enable signal low to stop capturing CHI messages in the SoC under test when there is no monitoring requirement, and set the enable signal high to resume capturing CHI messages in the SoC under test when there is a monitoring requirement, and output the transmission of CHI messages or monitoring results.

[0036] This embodiment of the on-chip network protocol hardware and software co-monitoring method implements a system-level verification method suitable for FPGA prototype platforms through a synthesizable and non-synthesizable two-part structure. It has low hardware resource consumption, low system cost, and quick and simple verification method. It can realize efficient monitoring and analysis of CHI protocol messages on the prototype platform, effectively accelerate the localization of SoC problems and performance analysis, and improve SoC design efficiency.

[0037] like Figure 2 As shown, this embodiment also provides a hardware-software collaborative monitoring device using the aforementioned hardware-software collaborative monitoring method, including an interconnected DPI-C interface (Direct Programming Interface for C) and an on-chip network protocol monitor (hereinafter referred to as the monitor). The monitor includes:

[0038] Data transmission module 1 is used to provide a shared function body declaration component 12 through synthesizable hardware to provide function bodies for shared use by software components; the non-synthesizable software components first instantiate the function bodies provided by the shared function body declaration component 12 to capture CHI messages in the SoC under test from various channels of the on-chip network protocol.

[0039] Data slice decoding and encoding module 2 is used to decode and encode CHI messages;

[0040] Protocol analysis model module 3 is used to perform specified protocol analysis processing on the grouped data packets;

[0041] The data transmission module 1 is connected to the CHI protocol signal in the SoC under test by binding. The data transmission module 1, the data chip decoding and coding module 2, and the protocol analysis model module 3 are connected in sequence. Among them, the data chip decoding and coding module 2 and the protocol analysis model module 3 are non-synthesized software parts.

[0042] See Figure 2In this embodiment, the data transmission module captures CHI messages in the SoC under test and transmits them from the FPGA prototype platform to the workstation via the DPI-C interface. The data chip decoding and coding module 2 processes the data chips in the CHI protocol, decodes the data chips according to the configuration information in the data transmission module 1, and codes the transaction flow control variables in the decoded data chip structure. The protocol analysis model module 3 can complete transaction flow tracking, message correctness verification, and message type coverage monitoring. The data transmission module 1 can output the CHI message directly without verification, or use the data chip decoding and coding module 2 and the protocol analysis model module 3 to decode, code, and perform specified protocol analysis on the CHI message before outputting the monitoring results. These correspond to two modes: in offline mode, the data transmission module 1 outputs the data packet and stores it in the workstation; in online mode, the data transmission module 1 transmits the data packet to the data chip decoding and coding module 2, which decodes and codes the data packet before transmitting it to the protocol analysis model module 3. The protocol analysis model module 3 then performs protocol analysis and outputs monitoring logs as monitoring results to the workstation.

[0043] In the data transmission module 1, the shared function body declaration component 12 declares function bodies shared by the hardware and software parts in the synthesizable hardware section via import. Furthermore, the storage parameter configuration component 11 is used to set the data storage method of the monitor, including the output locations of data files and log files, the location of the data packet parameter configuration file, and the node number of the monitored node. The monitoring status control component 13 is used to control the monitor's enable. When there is no need for monitor use, the monitor's enable signal is set low on the FPGA platform, stopping data transmission to the workstation via the DPI-C interface and reducing resource consumption. When there is a need for monitor use, the monitor's enable signal is set high, enabling the monitor to start working.

[0044] As an optional implementation, the non-synthesizable software portion of the data transmission module 1 can be implemented using C or C++. For example... Figure 3 As shown, the non-synthesizable software portion of the data transmission module 1 includes: a data slice parameter configuration module 14, used to set the field format of the CHI bus protocol data slice to support different CHI protocols, and to read the configurable parameter fields of the CHI protocol using a parameter input method. Specific parameters include address bit width, data bit width, node number bit width, transaction number bit width, and custom bit width. Since some fields in the CHI protocol standard are configurable, the actual implementation of the CHI protocol in each SoC under test is different. In this embodiment, the configurable parameter fields of the CHI protocol are specifically read using a parameter input method.

[0045] The monitor data management module 15 is used to instantiate the shared function body and to implement the data transmission of the main request channel, the slave data channel, the slave feedback channel, the slave listening channel, the main feedback channel, and the main data channel. Different data are identified by a unique handle index in the handle list.

[0046] The monitor mode control module 16 is used to select offline mode and online mode through macro definition. In offline mode, the CHI message is output directly without inspection. In online mode, the CHI message is decoded, grouped, and analyzed according to the specified protocol before the monitoring results are output.

[0047] In this embodiment, the monitor mode control module 16 outputs the CHI message directly without verification in offline mode, including:

[0048] Step 1: When the on-chip network protocol monitor enable signal is high, the monitoring clock starts counting, and a data file DAT is created according to the data file output position in the storage parameter configuration component 11. The handle of the data file DAT is then saved in the handle list in the monitor data management module 15.

[0049] Step 2: When the valid signal in the monitored channel is pulled high, the complete information of the data fragments in the channel, the monitoring clock count, and the channel type are transmitted to the workstation through the shared function body. The data file DAT handle is searched in the handle list according to the node number in the storage parameter configuration component 11, and the data is output in the data file DAT.

[0050] Step 3: When the on-chip network protocol monitor enable signal is low, close the data file DAT.

[0051] In this embodiment, the monitor mode control module 16 decodes, groups, and performs specified protocol analysis on the CHI message in online mode, and then outputs the monitoring results, including:

[0052] Step 1: When the on-chip network protocol monitor enable signal is high, the monitoring clock starts counting. According to the log file LOG output position in the storage parameter configuration component 11, the log file LOG is created and the handle of the log file LOG is saved in the handle list in the monitor data management module 15.

[0053] Step 2: When the valid signal in the monitored channel is pulled high, the complete information of the data slice, the monitoring clock count, and the channel type in the channel are transmitted to the workstation through the shared function body. The data slice decoding and coding module 2 and the protocol analysis model module 3 complete the protocol monitoring online. According to the node number in the storage parameter configuration component 11, the log file LOG handle is searched in the handle list, and the monitoring results are output in the log file LOG.

[0054] Step 3: When the on-chip network protocol monitor enable signal is low, close the log file LOG.

[0055] Data slice decoding group code module 2 includes:

[0056] The decoding module operates on data packets. Following the data fragment field format passed from the data packet parameter configuration module 14 in the data transmission module 1, it decodes the messages in the six channels of the CHI protocol—main request channel, slave data channel, slave feedback channel, slave listening channel, main feedback channel, and main data channel—according to the CHI protocol specification. The complete data fragment is decomposed into individual field information based on its bit width through shift and AND / OR operations. The decoded field information is stored in a data fragment structure. Taking the main request channel as an example, the decoded data fragment structure includes an identifier, target node number, source node number, logical process number, transaction number, opcode, address, data size, whether retry is allowed, credit protocol type, whether feedback confirmation is required, return node number, return transaction number, storage node number, storage node valid bit, storage logical process number, storage logical process valid bit, security attribute, memory attribute, listening attribute, shared attribute, exclusive access, sorting attribute, byte order, tracking flag, and custom bits. The identifier is a unique identifier generated during the decoding process for each transaction stream, facilitating subsequent problem localization.

[0057] The grouping module is used to parse the data in the data slice structure into transaction flow control variables. The transaction flow control variables specifically include whether the message is a no-data-type message, a listenable type message, an atomic type message, a message related to buffer state setting, or a DVM type message, as mapped according to the opcode field, and whether a feedback message is required, as mapped according to whether feedback confirmation is required. The decoding module and the grouping module are interconnected. The decoding module is connected to the output of the data transmission module 1. The output of the grouping module is used to output the grouped data packet DAT, and at the same time, the grouped data packet DAT is used as the input of the protocol analysis model module 3.

[0058] like Figure 4 As shown, the DAT data packet is in binary format, containing information such as the node's handle index, channel type, monitor clock count, and complete message. The node's handle index is the node number of the monitored node in the storage parameter configuration component 11. The channel type is an eight-bit binary number, with the lower four bits used to identify the channel in the message and the higher four bits used to indicate whether it is a credit return message. Since the DPI operation of the FPGA platform may be out of order, the monitor uses clock counting to mark the message's arrival time.

[0059] like Figure 5 As shown, the protocol analysis model module 3 in this embodiment includes:

[0060] The transaction flow tracing module 31 is used to convert the data sent by the data slice decoding and encoding module 2 into transaction flow data with the transaction flow order as the storage structure. The transaction flow data packet uses two transaction flow structures, request and listener, to store the transaction flow (since a transaction flow in the CHI protocol usually starts with a request or listener message, the transaction flow data packet uses two transaction flow structures, request and listener, to store the transaction flow).

[0061] The transaction flow structure includes a request or listener message, a set of data messages, a feedback message, a transaction flow counter, transaction flow operation parsing variables, and a structure initialization function. The transaction flow counter is used to mark the progress status of the transaction lifecycle (according to the CHI protocol specification, the types and number of subsequent transactions included in each transaction flow are fixed). Each time a message is detected, the transaction flow counter is decremented by one, and the transaction flow lifecycle ends when the counter reaches zero. The transaction flow operation parsing variables are used to determine the type of subsequent messages in the transaction flow, including: whether it is a message with no data type, whether it is a listenable message, whether it is an atomic message, whether it is a message related to cached state settings, and whether it is a DVM type message. The structure initialization function is used to initialize all transaction flow operation parsing variables, the initial value of the transaction counter, and the message.

[0062] The link layer verification module 32 is used to verify the correctness of six types of channel link layer data, including channel credit count verification and message link layer field verification.

[0063] Protocol layer verification module 33 is used to verify the correctness of six channel protocol layer transaction flows and to perform detailed transaction flow analysis and conflict monitoring.

[0064] Problem feedback module 34 is used to control the subsequent operations of the monitor when it detects a fatal error. When the link layer input module and the protocol layer verification module detect a problem, they actively report the error and output the complete information of the transaction flow where the problem occurred and the basic error message in the monitoring log. The simulation can be stopped or continued according to the monitor settings.

[0065] The transaction flow tracing module 31, the link layer verification module 32, and the protocol layer verification module 33 are connected in sequence. The link layer verification module 32 and the protocol layer verification module 33 are respectively connected to the problem feedback module 34.

[0066] The transaction flow tracing module 31 reads the packets of the six channels in the data packet in chronological order to realize transaction flow tracing of the six types of link layer data. The detailed steps include: S1: For the master request channel, when a request packet is detected, a request transaction flow structure is created, the structure is initialized, and the structure is stored in the transaction flow tracing list; S2: For the slave listening channel, when a listening packet is detected, a listening transaction flow structure is created, the structure is initialized, and the structure is stored in the transaction flow tracing list; S3: For the slave data channel, slave feedback channel, master feedback channel, and master data channel, when a data or feedback packet is detected, its ID field is checked, and the target node number, source node number, and transaction number are used to determine which transaction flow in the transaction flow tracing list the packet belongs to, and the packet is stored in the transaction flow structure; S4: S1-S3 are repeated to trace the transaction flow until the transaction flow lifecycle ends, the transaction flow is deleted from the transaction flow tracing list, and the transaction flow continues to be monitored in the packet parsing and verification module; As an optional implementation, the complete transaction flow lifecycle is output in the log file LOG.

[0067] The link layer verification module 32 is used to verify the correctness of six types of channel link layer data, including channel credit count verification and message link layer field verification. The input and credit counting method for transaction messages is as follows: if it is a transaction message, the credit count is decremented by one; if it is a credit return message, the credit count is incremented by one. An error is reported when the credit value is less than zero. The link layer field verification of the transaction flow includes checking whether the opcode field of the message is a value specified in the protocol specification; if it does not conform to the specification, an error is reported. The protocol layer conflict monitoring is used to monitor whether the message conforms to the CHI protocol specification; if it does not conform to the specification, an error is reported. This includes checking whether a listenable request message has a RESP message as a reply, whether the EXP_COMP_ACK field of the listenable request message is true, and whether the ORDER field of a non-listenable request message is 00.

[0068] See Figure 5 As an optional implementation, the protocol analysis model module 3 in this embodiment also includes a coverage monitoring module 35, which is used to monitor all messages in the data packet by channel. Each channel contains a message type count table to record the number of times each message type occurs. When a message is detected, the count of the transaction type corresponding to the current message opcode field is incremented by one. When the monitoring is completed, the number of occurrences of all message types in each channel and the coverage of message types are statistically output to the log file LOG.

[0069] In summary, this embodiment implements the monitoring function of the CHI bus. Through in-depth analysis of CHI bus signals, it successfully achieves transaction flow tracking and can proactively report errors such as transaction response errors, timeout errors, and insufficient credit on the bus, shortening the problem location time. By capturing channel messages, it achieves coverage analysis of protocol message types in the SoC. This embodiment designs a hardware and software co-implemented monitor, where the synthesizable part of the monitor is implemented on the FPGA prototype platform, and the non-synthesizable part is implemented on the workstation. The DPI-C mode is used to complete the SV to C transmission, which can reduce hardware resource consumption while performing efficient performance analysis. This embodiment implements a hardware and software collaborative monitoring function for CHI protocol signals. It can track transaction flows, proactively report bus transaction response errors, timeout errors, and insufficient credit issues, and achieve coverage analysis of protocol message types in the SoC. It can be used in software simulation and FPGA prototyping platforms to monitor and analyze on-chip network protocols in the SoC. By acquiring the bus transaction transmission status between various nodes of the CHI protocol, it can perform efficient performance analysis while reducing hardware resource consumption, efficiently complete protocol analysis, and achieve the purpose of assisting in locating problems encountered in verification. It can accelerate the location and performance analysis of SoC problems and improve SoC design efficiency.

[0070] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 a process or multiple processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0071] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiment. All technical solutions based on the concept of the present invention are within the scope of protection of the present invention. It should be noted that for those skilled in the art, various improvements and modifications that do not depart from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A hardware-software co-monitoring method for on-chip network protocols, characterized in that, This includes providing function bodies for shared use in the software section through a shared function body declaration component (12) in the synthesizable hardware section; and first instantiating the function bodies provided by the shared function body declaration component (12) in the non-synthesizable software section to capture CHI messages in the SoC under test from various channels of the on-chip network protocol. Then, in offline mode, the CHI messages are output directly without verification, or in online mode, the CHI messages are decoded, grouped, and analyzed according to the specified protocol before the monitoring results are output.

2. The hardware and software collaborative monitoring method for on-chip network protocols according to claim 1, characterized in that, It also includes a storage parameter configuration component (11) provided through synthesizable hardware to set data storage configuration information for use by non-synthesizable software, the data storage configuration information including the output location of data files and log files (LOG), the location of data packet parameter configuration files, and the node number of the SoC under test.

3. The hardware and software collaborative monitoring method for on-chip network protocols according to claim 2, characterized in that, It also includes a monitoring status control component (13) provided through synthesizable hardware, which is used to set the enable signal low to stop capturing CHI messages in the SoC under test when there is no monitoring requirement, and set the enable signal high to resume capturing CHI messages in the SoC under test when there is a monitoring requirement, and output the transmitted CHI messages or monitoring results.

4. A hardware-software co-monitoring device using the hardware-software co-monitoring method for on-chip network protocols according to any one of claims 1 to 3, comprising an interconnected DPI-C interface and an on-chip network protocol monitor, wherein the on-chip network protocol monitor comprises: The data transmission module (1) is used to provide a shared function body declaration component (12) through synthesizable hardware to provide a function body for shared use by the software part; the non-synthesizable software part first instantiates the function body provided by the shared function body declaration component (12) to capture CHI messages in the SoC under test from various channels through the on-chip network protocol; The data slice decoding and coding module (2) is used to decode and code CHI messages; Protocol analysis model module (3) is used to perform specified protocol analysis processing on the grouped data packets; The data transmission module (1) is connected to the CHI protocol signal in the SoC under test by binding. The data transmission module (1), the data chip decoding and coding module (2), and the protocol analysis model module (3) are connected in sequence. The data chip decoding and coding module (2) and the protocol analysis model module (3) are non-synthesized software parts.

5. The hardware and software collaborative monitoring device according to claim 4, characterized in that, The shared function body declaration component (12) in the data transmission module (1) declares the function body shared by the hardware part and the software part in the synthesizable hardware part by means of import.

6. The hardware and software collaborative monitoring device according to claim 5, characterized in that, The non-synthesizable software parts of the data transmission module (1) include: a data slice parameter configuration module (14), which is used to set the field format of the CHI bus protocol data slice to support different CHI protocols, and reads the configurable parameter fields of the CHI protocol using the parameter input method. The specific parameters include address bit width, data bit width, node number bit width, transaction number bit width, and custom bit width; a monitor data management module (15), which is used to complete the instantiation of the shared function body, and is used to realize the data transmission of the master request channel, slave data channel, slave feedback channel, slave listening channel, master feedback channel, and master data channel. Different data are identified by a unique handle index in the handle list; and a monitor mode control module (16), which is used to select the offline mode and the online mode through macro definition. In the offline mode, the CHI message is output directly without inspection. In the online mode, the CHI message is decoded, grouped, and analyzed by the specified protocol before the monitoring result is output.

7. The hardware and software collaborative monitoring device according to claim 6, characterized in that, The monitor mode control module (16) outputs CHI messages directly without inspection in offline mode, including: Step 1, when the on-chip network protocol monitor enable signal is high, the monitoring clock starts counting, a data file DAT is created according to the data file DAT output position in the storage parameter configuration component (11), and the handle of the data file DAT is saved in the handle list in the monitor data management module (15); Step 2, when the valid signal in the monitored channel is high, the complete information of the data chip, the monitoring clock count, and the channel type in the channel are transmitted to the workstation through the shared function body, and the handle of the data file DAT is searched in the handle list according to the node number in the storage parameter configuration component (11), and the data is output in the data file DAT; Step 3, when the on-chip network protocol monitor enable signal is low, the data file DAT is closed; The monitor mode control module (16) outputs CHI messages directly in online mode. After decoding, coding, and specified protocol analysis, the monitoring results are output as follows: Step 1, when the on-chip network protocol monitor enable signal is high, the monitoring clock starts counting. According to the log file LOG output position in the storage parameter configuration component (11), the log file LOG is created, and the log file LOG handle is saved in the handle list in the monitor data management module (15); Step 2, when the valid signal in the monitored channel is pulled high, the complete information of the data slice, the monitoring clock count, and the channel type in the channel are transmitted to the workstation through the shared function body. The data slice decoding and coding module (2) and the protocol analysis model module (3) complete the protocol monitoring online. According to the node number in the storage parameter configuration component (11), the log file LOG handle is searched in the handle list, and the monitoring results are output in the log file LOG; Step 3, when the on-chip network protocol monitor enable signal is low, the log file LOG is turned off.

8. The hardware and software collaborative monitoring device according to claim 7, characterized in that, The data slice decoding and coding module (2) includes: a decoding module, used to operate on data packets, and according to the data slice field format passed in the data packet parameter configuration module (14) in the data transmission module (1), decode the messages in the six channels of the CHI protocol—main request channel, slave data channel, slave feedback channel, slave listening channel, main feedback channel, and main data channel—according to the CHI protocol specification, decompose the complete data slice into various field information according to the bit width through shift and AND / OR operations, and store the decoded field information in the data slice structure; and a coding module, used to parse the data in the data slice structure into... Transaction flow control variables; the transaction flow control variables specifically include whether the message is a no-data-type message, a listenable type message, an atomic type message, a cache state setting related message, or a DVM type message, as mapped according to the opcode field, and whether a feedback message is needed, as mapped according to whether feedback confirmation is performed; the decoding module and the coding module are interconnected, the decoding module is connected to the output of the data transmission module (1), and the output of the coding module is used to output the coded data packet, and at the same time, the coded data packet is used as the input of the protocol analysis model module (3).

9. The hardware and software collaborative monitoring device according to claim 8, characterized in that, The protocol analysis model module (3) includes: The transaction flow tracing module (31) is used to convert the data sent by the data slice decoding group code module (2) into transaction flow data with the transaction flow order as the storage structure. The transaction flow data packet uses two types of transaction flow structures, request and listener, to store the transaction flow. The transaction flow structure includes a request or listener message, a set of data messages, a feedback message, a transaction flow count, transaction flow operation parsing variables, and a structure initialization function. The transaction flow count is used to mark the progress status of the transaction life cycle. Each time a message is detected, the transaction flow count is decremented by one. When the count is zero, the transaction flow life cycle ends. The transaction flow operation parsing variables are used to determine the type of subsequent messages in the transaction flow, including: whether it is a message with no data type, whether it is a message that can be listened to, whether it is an atomic type message, whether it is a message related to cached state setting, and whether it is a DVM type message. The structure initialization function is used to initialize all transaction flow operation parsing variables, the initial value of the transaction count, and the message. The link layer verification module (32) is used to verify the correctness of six types of channel link layer data, including channel credit count verification and message link layer field verification. The protocol layer verification module (33) is used to verify the correctness of six channel protocol layer transaction flows and to perform detailed transaction flow analysis and conflict monitoring. Problem feedback module (34) is used to control the subsequent operations of the monitor when it finds a fatal error. When the link layer input module and the protocol layer verification module detect that a problem has occurred, the module actively reports the error and outputs the complete information of the transaction flow where the problem occurred and the basic error message in the monitoring log. The module can choose to stop or continue the simulation according to the settings of the monitor. The transaction flow tracing module (31), the link layer verification module (32), and the protocol layer verification module (33) are connected in sequence. The link layer verification module (32) and the protocol layer verification module (33) are respectively connected to the problem feedback module (34).

10. The hardware and software collaborative monitoring device according to claim 9, characterized in that, The protocol analysis model module (3) also includes a coverage monitoring module (35), which monitors all messages in the data packet by channel. Each channel contains a message type count table to record the number of times each message type occurs. When a message is detected, the count of the transaction type corresponding to the current message opcode field is incremented by one. When the monitoring is completed, the number of occurrences of all message types in each channel and the coverage of message types are statistically output to the log file LOG.

Images