An AXI bus delay monitoring system, method and computer device

Abstract

The application provides an AXI bus delay monitoring system, method and computer equipment, and the system comprises: a time stamp recording area which stores time stamps corresponding to different AXI_IDs of each AXI command in the form of a linked list; a resource application module which applies a free entry in the time stamp recording area to store a first AXI_ID and a first time stamp corresponding to a new AXI command when the new AXI command appears on a transaction request path; a resource release module which determines the order of a linked list corresponding to a second AXI_ID in the time stamp recording area according to the second AXI_ID, obtains a first time stamp stored in a head position and generates a second time stamp when a new AXI command appears on a transaction response path; and a delay analysis module which is used for calculating a bus delay value of a target AXI_ID according to the first time stamp and the second time stamp. The scheme can realize monitoring of any target AXI_ID and reduces hardware resource consumption.

Description

Technical Field

[0001] This invention relates to the field of delay monitoring technology, and more particularly to an AXI bus delay monitoring system, method and computer device. Background Technology

[0002] In System-on-Chip (SoC), monitoring the performance of the AXI bus is necessary to ensure data transmission efficiency, meet design specifications, optimize resource allocation, and guarantee system reliability. However, accurate performance monitoring of the AXI bus in an SoC faces a trade-off between resources and flexibility. Traditional solutions directly link hardware resource consumption to the number of AXI_IDs to be monitored. Each possible AXI_ID requires a timestamp storage area of ​​depth N (where N is the maximum number of concurrent transactions) to handle the potential for N concurrent transactions with the same ID. This results in significant hardware resource consumption, and the area of ​​the monitoring module increases linearly with the number of AXI buses. Therefore, a solution is urgently needed that can reduce hardware resource consumption and provide complete and accurate monitoring of any target AXI_ID. Summary of the Invention

[0003] The purpose of this invention is to provide an AXI bus delay monitoring system, method, and computer device that can achieve complete and accurate monitoring of any target AXI_ID, while reducing hardware resource consumption and thus saving chip area.

[0004] The technical solution provided by this invention is as follows: In a first aspect, this application provides an AXI bus delay monitoring system, comprising: The timestamp recording area is used to store the timestamp information of different AXI_IDs corresponding to each AXI command on the transaction request path in the form of a linked list. The depth of the timestamp recording area is the maximum number of transactions that the on-chip system can perform simultaneously. A timestamp timer is used to generate a timestamp for each AXI command that appears on the transaction request path; The resource request module is configured to, when a new AXI command appears on the transaction request path, request a free entry in the timestamp record area to store the first AXI_ID and the first timestamp corresponding to the AXI command, and update the linked list order of each entry in the timestamp record area corresponding to the first AXI_ID. The resource release module is configured to, when a new AXI command appears in the transaction response path, determine the order of the linked list corresponding to the second AXI_ID in the timestamp record area according to the second AXI_ID corresponding to the AXI command, obtain the first timestamp stored in the first entry at the head position of the linked list order, release the first entry, and generate a second timestamp through the timestamp timer. The delay analysis module is used to obtain the first timestamp and the second timestamp corresponding to the target AXI_ID according to the configuration information, and calculate the bus delay value of the target AXI_ID.

[0005] In some implementations, the data structure of each entry in the timestamp recording area includes at least a current ID recording area, a timestamp recording area, a current ID head pointer position indicator area, a current ID tail pointer position indicator area, and a current ID corresponding linked list next hop address recording area.

[0006] In some implementations, the resource request module is used to identify the first AXI_ID corresponding to the new first AXI command when a new first AXI command appears on the transaction request path, and to initiate a resource request to the timestamp recording area, so that the timestamp recording area allocates a free second entry to store the first AXI_ID and the corresponding first timestamp; When responding to the resource request, the timestamp recording area searches for the first linked list order corresponding to the first AXI_ID in the timestamp recording area; adjusts the state of the current ID tail pointer position indicator area in the third entry located at the tail position in the first linked list order, so that the third entry no longer indicates the tail position in the first linked list order; and adjusts the state of the current ID tail pointer position indicator area in the second entry, and sets the address of the second entry to the next hop address of the third entry, thereby updating the first linked list order so that the second entry indicates the new tail position in the first linked list order.

[0007] In some implementations, the resource release module is used to identify the second AXI_ID corresponding to the new second AXI command when a new second AXI command appears in the transaction response path, and search for the second linked list order corresponding to the second AXI_ID in the timestamp record area using the second AXI_ID as an index; The timestamp recording area obtains the first timestamp stored in the first entry located at the head position in the second linked list sequence, and releases the first entry. At the same time, it generates a second timestamp through the timestamp timer. According to the next hop address of the linked list recorded by the first entry, it adjusts the current ID head pointer position indication area state of the corresponding fourth entry in the second linked list sequence so that the fourth entry indicates the new head position in the second linked list sequence.

[0008] In some implementations, if there is no storage record corresponding to the first AXI_ID in the timestamp record area when responding to the resource request, the state of the current ID head pointer position indicator area and the current ID tail pointer position indicator area in the second entry are adjusted simultaneously to form the first linked list order containing only the second entry.

[0009] In some implementations, the delay analysis module includes a programmable register for configuring ID information and an ID mask for the AXI bus, so as to adjust the target AXI_ID to be monitored by adjusting the value of the register.

[0010] In some implementations, the register is also used to configure the upper and lower boundary values ​​of different levels of the monitoring range; The monitoring system also includes a performance statistics unit, which is used to count the bus delay value of the target AXI_ID in different monitoring intervals and perform performance analysis.

[0011] In some implementations, the resource release module is also used to compare the second AXI_ID corresponding to the new AXI command with the ID information configured by the latency analysis module when a new AXI command appears in the transaction response path, and output a statistical analysis indication signal to the performance statistics unit when the comparison is the same.

[0012] Secondly, this application provides an AXI bus delay monitoring method, including: The timestamp recording area is set up to store the timestamp information of different AXI_IDs corresponding to each AXI command on the transaction request path in the form of a linked list. The depth of the timestamp recording area is the maximum number of transactions that the on-chip system can perform simultaneously. Set a timestamp timer to generate a timestamp for each AXI command that appears on the transaction request path; When a new AXI command appears on the transaction request path, a free entry is requested in the timestamp record area to store the first AXI_ID and the first timestamp corresponding to the AXI command, and the linked list order of each entry corresponding to the first AXI_ID in the timestamp record area is updated. When a new AXI command appears in the transaction response path, the order of the linked list corresponding to the second AXI_ID in the timestamp record area is determined according to the second AXI_ID corresponding to the AXI command. The first timestamp stored in the first entry at the head position in the linked list order is obtained, the first entry is released, and the second timestamp is generated through the timestamp timer. Based on the configuration information, obtain the first timestamp and the second timestamp corresponding to the target AXI_ID, and calculate the bus delay value of the target AXI_ID.

[0013] Thirdly, this application provides a computer device including the AXI bus delay monitoring system described in the first aspect.

[0014] The AXI bus delay monitoring system, method, and computer device provided by the present invention can achieve complete and accurate monitoring of any target AXI_ID, and can reduce hardware resource consumption, thereby saving chip area; at the same time, by reconfiguring ID filtering rules and upper and lower boundary ranges of each time interval through software, the ID to be monitored can be switched at any time during system operation without interrupting or stopping services, so as to achieve accurate delay monitoring and performance statistical analysis of specific target IDs. Attached Figure Description

[0015] The preferred embodiments will now be described in a clear and easy-to-understand manner, with reference to the accompanying drawings, to further explain the above-mentioned characteristics, technical features, advantages, and implementation methods of this solution.

[0016] Figure 1 This is a schematic diagram of the overall architecture of one embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of each entry in the timestamp recording area in one embodiment of the present invention; Figure 3 This is a schematic representation of a timestamp record chain according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the overall process of one embodiment of the present invention.

[0017] Icon labels: 10 - Timestamp recording area; 20 - Timestamp timer; 30 - Resource request module; 40 - Resource release module; 50 - Latency analysis module; 60 - Performance statistics unit. Detailed Implementation

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the specific implementation methods of the present invention will be described below with reference to the accompanying drawings. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings and other implementation methods can be obtained based on these drawings without any creative effort.

[0019] To keep the drawings concise, only the parts relevant to the invention are shown schematically in each figure, and they do not represent the actual structure of the product. Furthermore, for ease of understanding, in some figures, only one of components with the same structure or function is shown schematically, or only one is labeled. In this document, "one" can mean not only "only one" but also "more than one".

[0020] In System-on-Chip (SoC), monitoring the performance of the AXI bus is necessary to ensure data transmission efficiency, meet design specifications, optimize resource allocation, and guarantee system reliability. However, accurate performance monitoring of the AXI bus in an SoC faces a trade-off between resources and flexibility. Traditional solutions directly link hardware resource consumption to the number of AXI_IDs to be monitored. Each possible AXI_ID requires a timestamp recording storage area of ​​depth N (where N is the maximum number of concurrent transactions, which can be named "Outstanding") to handle the potential for N concurrent transactions with the same ID. This leads to significant hardware resource consumption, and the area of ​​the monitoring module increases linearly with the number of AXI buses. Furthermore, current ID filtering operations typically involve matching the ID of the transaction request path with configured filtering rules, recording and storing the timestamps after a match, and then waiting for the corresponding ID to be returned before performing latency statistics for that ID. The drawback of this approach is that every time you need to switch to monitoring the latency of other IDs, you need to stop the current business, configure the new ID filtering rules, and then start the business again to achieve accurate monitoring. This is because it is necessary to ensure that the information of the previous monitored ID in the timestamp record area has been completely processed or that the residual information in the storage needs to be cleared to avoid affecting the accuracy of the new ID detection.

[0021] Therefore, there is an urgent need for a solution that can reduce hardware resource consumption and provide complete and accurate monitoring of any target AXI_ID. This solution transforms the massive, static, ID-allocated hardware resources into general-purpose timestamp recording units based on Outstanding depth. Each entry records the ID and start timestamp of an ongoing transaction. Storage resources for this timestamp recording area are managed using a linked list, dynamically allocating and releasing corresponding entries to achieve on-demand shared timestamp recording areas among different IDs. Then, combined with configurable dynamic ID filtering, each transaction ID on the bus is compared against the configured ID filtering rules, accurately serving the most critical bus transactions without interrupting business operations. For transactions that meet the filtering rules, subsequent performance statistics and analysis are performed, achieving flexible and comprehensive bus latency monitoring of an unlimited number of IDs with limited hardware resources (area). The following is a detailed description of this solution with reference to the accompanying diagram: In one embodiment, refer to the appendix to the specification. Figure 1 This application provides an AXI bus delay monitoring system, including a timestamp recording area 10, a timestamp timer 20, a resource request module 30, a resource release module 40, and a delay analysis module 50.

[0022] The timestamp recording area 10 is used to store the timestamp information of different AXI_IDs corresponding to each AXI command on the transaction request path in the form of a linked list. The depth of the timestamp recording area is the maximum number of transactions that the on-chip system can perform simultaneously.

[0023] Timestamp recording area 10 is a storage structure used to store the timestamps corresponding to different IDs on the transaction request path. Its depth N is determined by the maximum number of Outstanding transactions supported by the design. The storage location relationship of all IDs is maintained in the form of a linked list. Each entry in the storage structure represents the information of an AXI_ID.

[0024] In one specific implementation, the data structure of each entry in the timestamp recording area 10 includes at least a current ID recording area, a timestamp recording area, a current ID head pointer position indicator area, a current ID tail pointer position indicator area, and a current ID corresponding linked list next-hop address recording area. The current ID recording area records the current AXI_ID corresponding to the timestamp stored in the entry; the timestamp recording area records the timestamp corresponding to the current AXI_ID; the current ID head pointer position indicator area indicates whether the current entry is at the head of the linked list; the current ID tail pointer position indicator area indicates whether the current entry is at the tail of the linked list; and the current ID corresponding linked list next-hop address recording area indicates the next-hop address of the linked list corresponding to the current entry, thus reflecting the linked list order (i.e., the AXI command order) of each entry corresponding to each AXI_ID. For an example, refer to the attached specification. Figure 2 V represents valid, set to 1 when the current entry is valid; H represents head, used to indicate the head pointer position of the current ID; T represents tail, used to indicate the tail pointer position of the current ID; axid represents the value of the current ID; next_ptr represents the address of the next hop in the linked list corresponding to the current ID; Timer: represents the specific value of the timestamp recorded at this time, and each entry in the timestamp recording area 10 can be stored using this data structure. Of course, other data structures can also be used to store the corresponding information in other embodiments, and this application does not impose any restrictions. In one example, there are 3 transactions with AXID, where axid=1 has 3 commands, Axid=2 has 2 commands, and axid=3 has 2 commands. Different IDs arrive in the order of 1, 2, 3, 1, 1, 2, 3 on the request path. Then the storage method of the linked list can be as shown in the appendix. Figure 3 As shown.

[0025] The timestamp timer 20 is used to generate a corresponding timestamp for each AXI command appearing on the transaction request path. Since this scheme uses a single timestamp timer 20 and can generate a corresponding timestamp for each AXI command appearing on the transaction request path, the timestamp timer 20 will continue to work after the module is enabled, counting the AXI bus clock to generate real-time timestamp information for each AXI command.

[0026] The resource request module 30 is configured to request a free entry in the timestamp record area 10 when a new AXI command appears on the transaction request path, to store the first AXI_ID and the first timestamp corresponding to the AXI command, and to update the linked list order of each entry in the timestamp record area 10 corresponding to the first AXI_ID.

[0027] When a new AXI command arrives on the transaction request path, this application will identify and confirm its AXI_ID (for easy distinction, it can be named the first AXI_ID), and then initiate a resource request. The system will dynamically allocate a free entry from the timestamp record resource pool in timestamp record area 10 to this transaction ID, and then store the current timestamp into the requested free entry.

[0028] Furthermore, since the timestamp recording area 10 of this application stores the timestamp information corresponding to different AXI_IDs in the form of a linked list, and each AXI_ID may correspond to a different number of entries, and the storage order of each entry defined by each AXI_ID is particularly important, this application also updates the information of other entries in the linked list order corresponding to each AXI_ID when storing an AXI_ID and related timestamp information in the timestamp recording area 10, especially the information in the current ID head pointer position indicator area, the current ID tail pointer position indicator area, and the current ID corresponding linked list next jump address recording area related to the linked list order. For each newly stored AXI_ID and related timestamp information, the current linked list tail of the corresponding ID is found in the linked list, the new application address is stored in the linked list tail field, and the next jump address of the linked list and the head and tail indicator information of the linked list are maintained, so that the entry corresponding to the currently stored AXI_ID and related timestamp information becomes the tail of the linked list corresponding to that ID.

[0029] In one specific implementation, the resource request module 30 is used to identify the first AXI_ID corresponding to the new first AXI command when a new first AXI command appears on the transaction request path, and to initiate a resource request to the timestamp recording area 10, so that the timestamp recording area 10 allocates a free second entry to store the first AXI_ID and the corresponding first timestamp.

[0030] When the AXI bus transmits data, AXI commands appear on the transaction request path to request resources, and each AXI command has its own corresponding AXI_ID. Similarly, during the response phase, AXI commands appear on the transaction response path to confirm the response completion, and each AXI command also has its own AXI_ID. The AXI commands appearing on the transaction request path and the transaction response path are essentially the same, but for distinction, the AXI commands appearing on the transaction request path can be named the first AXI command, and the AXI commands appearing on the transaction response path can be named the second AXI command. When a new first AXI command appears on the transaction request path to request resources from timestamp recording area 10, the free entry allocated in timestamp recording area 10 can be named the second entry.

[0031] When responding to a resource request, the timestamp recording area 10 searches for the first linked list order corresponding to the first AXI_ID in the timestamp recording area 10; by adjusting the state of the current ID tail pointer position indicator area in the third entry located at the tail position in the first linked list order, the third entry no longer indicates the tail position in the first linked list order; at the same time, by adjusting the state of the current ID tail pointer position indicator area in the second entry, and setting the address of the second entry to the next-hop address of the third entry, the first linked list order is updated, so that the second entry indicates the new tail position in the first linked list order.

[0032] When storing the timestamp information of each AXI_ID in the timestamp recording area 10, it uses a linked list. As transaction requests and responses continue, the linked list is constantly updated. Therefore, to distinguish the state of the linked list during a transaction request and the state of the linked list during a transaction response, the storage order of the linked list for each AXI_ID in the timestamp recording area 10 during a transaction request can be named the first linked list order. Correspondingly, when the linked list needs to release the corresponding entries in a subsequent transaction response, the storage order of the linked list for each AXI_ID can be named the second linked list order. Similarly, as transactions continue, the linked list is constantly updated, and the head and tail positions of the linked list also change continuously. To distinguish them, this application names the free entry allocated in timestamp record area 10 each time a resource is requested as the second entry. The second entry corresponds to the new tail position of the linked list, while the entry corresponding to the original tail position can be named the third entry. When a transaction is responded to, the entry at the head position of the linked list corresponding to each AXI_ID is released. This entry can be named the first entry, and then the second entry at the original head of the linked list becomes the new head position of the linked list, which can be named the fourth entry.

[0033] Of course, if there is no storage record corresponding to the first AXI_ID in the timestamp record area 10 when responding to resource requests, the state of the current ID head pointer position indicator area and the current ID tail pointer position indicator area in the second entry will be adjusted at the same time to form a first linked list order that only contains the second entry.

[0034] The resource release module 40 is configured to, when a new AXI command appears in the transaction response path, determine the linked list order corresponding to the second AXI_ID in the timestamp record area 10 according to the second AXI_ID corresponding to the AXI command, obtain the first timestamp stored in the first entry located at the head position in the linked list order, release the first entry, and generate a second timestamp through the timestamp timer.

[0035] When a new command is detected on the event response path, the system will use the current AXI_ID (which can be named the second AXI_ID for easy distinction) as an index to search for the head position of the linked list corresponding to the AXI_ID in the timestamp record area 10, obtain the timestamp information stored in this entry, and release this entry to make it an idle entry for the next monitored transaction to use, thereby realizing the dynamic allocation of each entry in the timestamp record area 10.

[0036] In one specific implementation, the resource release module 40 is used to identify the second AXI_ID corresponding to the new second AXI command when a new second AXI command appears in the transaction response path, and search for the second linked list order corresponding to the second AXI_ID in the timestamp record area 10 using the second AXI_ID as an index.

[0037] The timestamp recording area 10 obtains the first timestamp stored in the first entry located at the head position in the second linked list sequence, and releases the first entry. At the same time, it generates a second timestamp through the timestamp timer 20. According to the next jump address of the linked list recorded by the first entry, the state of the current ID head pointer position indicator area of ​​the corresponding fourth entry in the second linked list sequence is adjusted so that the fourth entry is at the new head position in the second linked list sequence.

[0038] The delay analysis module 50 is used to obtain the first and second timestamps corresponding to the target AXI_ID based on the configuration information, and to calculate the bus delay value of the target AXI_ID.

[0039] Specifically, on the transaction response path, when searching for and releasing the entry at the head of the linked list corresponding to the target AXI_ID in the timestamp record area 10, the stored start timestamp value (i.e., the first timestamp) is read and then subtracted from the current timestamp (i.e., the second timestamp) to calculate the bus delay value of the target AXI_ID.

[0040] In existing technologies, when selecting a target AXI_ID for monitoring, the process typically involves first matching the ID filtering rules along the transaction request path, then storing the timestamp, and finally waiting for the corresponding ID to be returned before performing latency statistics for that ID. The drawback of this approach is that each time the latency of a different ID needs to be monitored, the current service must be stopped, the new ID filtering rules configured, and then the service restarted for accurate monitoring. This is because it's necessary to ensure that the information for the previously monitored ID in the timestamp recording area has been completely processed or that any residual information in the storage has been cleared to avoid affecting the accuracy of the new ID detection. This proposed solution, however, performs ID filtering rule matching on the AXI_ID along the transaction response path. Only the timestamp of a matched AXI_ID is processed subsequently. This method allows for dynamic modification of register values ​​based on specific business needs without stopping the service, enabling complete and accurate monitoring of any target AXI_ID while reducing hardware resource consumption and saving chip area.

[0041] In one embodiment, based on the foregoing embodiments, the delay analysis module 50 includes a programmable register for configuring the ID information and ID mask of the AXI bus, so as to adjust the target AXI_ID to be monitored by adjusting the value of the register.

[0042] Flexible ID filtering rules can be implemented based on different combinations of ID and ID_MASK. Users can dynamically modify the register value according to specific business needs without stopping business operations, and realize latency monitoring, recording, and performance statistical analysis of any specific AXI_ID.

[0043] In some specific implementations, the register is also used to configure the upper and lower boundary values ​​of different levels of the monitoring interval. For example, four monitoring intervals can be set: 100μs-500μs, 500μs-1000μs, 1000μs-5000μs, and 5000μs-1ms. The monitoring system also includes a performance statistics unit 60, which is used to count the bus latency values ​​of the target AXI_ID in different monitoring intervals and perform performance analysis.

[0044] This solution compares the calculated latency value of an ID matched by the filtering rules with the boundary values ​​of different latency monitoring intervals configured in the performance statistics analysis. When a matching interval is found, the count of commands within that latency interval is incremented by 1. By continuously collecting latency data, latency performance statistics for different time intervals can be obtained. Simultaneously, the maximum latency value and its corresponding ID within the statistical period are recorded for easy debugging.

[0045] This solution also supports resetting the statistical values ​​of performance statistics unit 60. Each time the ID filtering rules are dynamically switched, only the performance statistics value needs to be reset to zero, without affecting the monitoring function unit. This decouples the monitoring function from the performance statistics, thereby achieving dynamic ID filtering.

[0046] In some specific implementations, the resource release module 40 is also used to compare the second AXI_ID corresponding to the new AXI command with the ID information configured by the delay analysis module 50 when a new AXI command appears in the transaction response path, and output a statistical analysis indication signal to the performance statistics unit 60 when the comparison is the same.

[0047] This solution compares the ID of each transaction response with the configured filtering rules and outputs an indication signal indicating whether performance statistical analysis should be performed on this ID. If the ID and filtering rules fail to match, the delay value is ignored; if the match is successful, subsequent performance statistical analysis is performed.

[0048] This solution resolves the conflict between resources and flexibility encountered when performing accurate performance monitoring of the AXI bus within a SoC. Specifically, it includes: (1) Decoupling of hardware area resource consumption from monitoring scope: In traditional solutions, hardware resource consumption is directly linked to the number of AXI_IDs to be monitored, and the timestamp of each command is stored in terms of AXI_ID dimension. This invention links resource consumption to the system's Outstanding depth (i.e., the maximum number of transactions in progress simultaneously). A general timestamp record storage area of ​​fixed size (depth N, where N is the Outstanding depth) is used to cover and support the monitoring of all IDs. This breaks the limitation that resource overhead increases linearly with the number of IDs.

[0049] (2) Dynamic ID Filtering: This invention introduces a flexible dynamic ID filtering mechanism. Users can dynamically specify one or a group of AXI_IDs that need to be monitored during system operation without stopping business. Only transactions with matching IDs will be subject to system statistical analysis. This achieves flexible configurability and accuracy of monitoring targets.

[0050] (3) Performance statistical analysis: The latency monitoring interval is dynamically configurable: the latency time interval that the business needs to monitor supports multiple levels, and the upper and lower boundaries of each level are configurable. Users can set the corresponding latency interval according to the specific business module for performance statistics and analysis.

[0051] In one embodiment, based on the foregoing embodiments, refer to the appendix to the specification. Figure 4 This application provides an AXI bus delay monitoring method, including: S100: Set the timestamp recording area to store the timestamp information of each AXI command corresponding to a different AXI_ID on the transaction request path in the form of a linked list. The depth of the timestamp recording area is the maximum number of transactions that the on-chip system can perform simultaneously. S200, Set a timestamp timer to generate a corresponding timestamp for each AXI command that appears on the transaction request path; S300. When a new AXI command appears on the transaction request path, a free entry is requested in the timestamp record area to store the first AXI_ID and the first timestamp corresponding to the AXI command, and the linked list order of each entry corresponding to the first AXI_ID in the timestamp record area is updated. S400: When a new AXI command appears in the transaction response path, determine the order of the linked list corresponding to the second AXI_ID in the timestamp record area according to the second AXI_ID corresponding to the AXI command, obtain the first timestamp stored in the first entry at the head position in the linked list order, release the first entry, and generate the second timestamp through the timestamp timer. S500: Obtain the first and second timestamps corresponding to the target AXI_ID based on the configuration information, and calculate the bus delay value of the target AXI_ID.

[0052] The technical concept of this AXI bus delay monitoring method is the same as that of the AXI bus delay monitoring system in the aforementioned embodiment, and will not be described again here.

[0053] In one embodiment, based on the foregoing embodiments, this application provides a computer device including the AXI bus delay monitoring system of the foregoing embodiments.

[0054] The technical concept of this computer device is the same as that of the AXI bus delay monitoring system in the aforementioned embodiment, and will not be described in detail here.

[0055] It should be noted that the above embodiments can be freely combined as needed. The above description is only a preferred embodiment of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. An AXI bus delay monitoring system, characterized in that, include: The timestamp recording area is used to store the timestamp information of different AXI_IDs corresponding to each AXI command on the transaction request path in the form of a linked list. The depth of the timestamp recording area is the maximum number of transactions that the on-chip system can perform simultaneously. A timestamp timer is used to generate a timestamp for each AXI command that appears on the transaction request path; The resource request module is configured to, when a new AXI command appears on the transaction request path, request a free entry in the timestamp record area to store the first AXI_ID and the first timestamp corresponding to the AXI command, and update the linked list order of each entry in the timestamp record area corresponding to the first AXI_ID. The resource release module is configured to, when a new AXI command appears in the transaction response path, determine the order of the linked list corresponding to the second AXI_ID in the timestamp record area according to the second AXI_ID corresponding to the AXI command, obtain the first timestamp stored in the first entry at the head position of the linked list order, release the first entry, and generate a second timestamp through the timestamp timer. The delay analysis module is used to obtain the first timestamp and the second timestamp corresponding to the target AXI_ID according to the configuration information, and calculate the bus delay value of the target AXI_ID; the delay analysis module includes a programmable register, which is used to configure the ID information and ID mask of the AXI bus, so as to adjust the target AXI_ID to be monitored by adjusting the value of the register; the register is also used to configure the upper and lower boundary values ​​of different levels of the monitoring interval; The performance statistics unit is used to count the bus latency value of the target AXI_ID in different monitoring intervals and perform performance analysis. The resource release module is also used to compare the second AXI_ID corresponding to the new AXI command with the ID information configured by the latency analysis module when a new AXI command appears in the transaction response path, and output a statistical analysis indication signal to the performance statistics unit when the comparison is the same.

2. The AXI bus delay monitoring system according to claim 1, characterized in that, The data structure of each entry in the timestamp recording area includes at least the current ID recording area, the timestamp recording area, the current ID head pointer position indicator area, the current ID tail pointer position indicator area, and the current ID corresponding linked list next hop address recording area.

3. The AXI bus delay monitoring system according to claim 2, characterized in that, The resource request module is used to identify the first AXI_ID corresponding to the new first AXI command when a new first AXI command appears on the transaction request path, and to initiate a resource request to the timestamp recording area, so that the timestamp recording area allocates a free second entry to store the first AXI_ID and the corresponding first timestamp. When responding to the resource request, the timestamp recording area searches for the first linked list order corresponding to the first AXI_ID in the timestamp recording area; adjusts the state of the current ID tail pointer position indicator area in the third entry located at the tail position in the first linked list order, so that the third entry no longer indicates the tail position in the first linked list order; and adjusts the state of the current ID tail pointer position indicator area in the second entry, and sets the address of the second entry to the next hop address of the third entry, thereby updating the first linked list order so that the second entry indicates the new tail position in the first linked list order.

4. The AXI bus delay monitoring system according to claim 2, characterized in that, The resource release module is used to identify the second AXI_ID corresponding to the new second AXI command when a new second AXI command appears in the transaction response path, and to search for the second linked list order corresponding to the second AXI_ID in the timestamp record area using the second AXI_ID as the index. The timestamp recording area obtains the first timestamp stored in the first entry located at the head position in the second linked list sequence, releases the first entry, and generates a second timestamp through the timestamp timer. And based on the next-hop address of the linked list recorded in the first entry, adjust the current ID head pointer position indication area state of the corresponding fourth entry in the second linked list order so that the fourth entry indicates the new head position in the second linked list order.

5. The AXI bus delay monitoring system according to claim 3, characterized in that, If, when responding to the resource request, there is no storage record corresponding to the first AXI_ID in the timestamp record area, then the states of the current ID head pointer position indicator area and the current ID tail pointer position indicator area in the second entry are adjusted simultaneously to form the first linked list order containing only the second entry.

6. An AXI bus delay monitoring method, based on the AXI bus delay monitoring system according to any one of claims 1-5, characterized in that, include: The timestamp recording area is set up to store the timestamp information of different AXI_IDs corresponding to each AXI command on the transaction request path in the form of a linked list. The depth of the timestamp recording area is the maximum number of transactions that the on-chip system can perform simultaneously. Set a timestamp timer to generate a timestamp for each AXI command that appears on the transaction request path; When a new AXI command appears on the transaction request path, a free entry is requested in the timestamp record area to store the first AXI_ID and the first timestamp corresponding to the AXI command, and the linked list order of each entry corresponding to the first AXI_ID in the timestamp record area is updated. When a new AXI command appears in the transaction response path, the order of the linked list corresponding to the second AXI_ID in the timestamp record area is determined according to the second AXI_ID corresponding to the AXI command. The first timestamp stored in the first entry at the head position of the linked list is obtained, the first entry is released, and the second timestamp is generated through the timestamp timer. Based on the configuration information, obtain the first timestamp and the second timestamp corresponding to the target AXI_ID, and calculate the bus delay value of the target AXI_ID.

7. A computer device, characterized in that, Includes the AXI bus delay monitoring system as described in any one of claims 1-5.

Images