System on chip, electronic device, chip and working method

Abstract

The present disclosure relates to a system on chip, electronic equipment and working method, and relates to the technical field of integrated circuits. The system on chip comprises a plurality of agent modules and a system interconnect bus module, each agent module being connected with the system interconnect bus module; any agent module comprises a transaction monitoring module, the transaction monitoring module being configured to filter transactions according to a preset filtering condition to obtain filtered transactions, and to perform performance testing on each agent module according to the filtered transactions. The filtering function is introduced in the performance testing, the data volume of the transactions is reduced, and thus the testing efficiency is improved.

Description

Technical Field

[0001] This disclosure relates to the field of integrated circuit technology, and in particular to a system-on-a-chip, electronic device, chip, and method of operation. Background Technology

[0002] In a System-on-Chip (SOC), different agent modules are interconnected via the System Fabric bus. Whether the transmission performance of the SOC meets expectations directly affects the stability, reliability, and scalability of the on-chip network. Therefore, testing the transmission performance of the SOC in simulation testing is crucial.

[0003] To test the transmission performance of an on-chip system, it is usually necessary to test the performance of the proxy modules connected to the system interconnect bus.

[0004] The current testing solution is relatively inefficient. Summary of the Invention

[0005] This disclosure provides a system-on-a-chip, an electronic device, a chip, and a method of operation.

[0006] According to a first aspect of the present disclosure, a system-on-a-chip is provided, comprising: a plurality of proxy modules and a system interconnect bus module, wherein each of the proxy modules is connected to the system interconnect bus module; wherein any one of the proxy modules includes a transaction monitoring module, the transaction monitoring module being configured to filter transactions according to preset filtering conditions to obtain filtered transactions, and to perform performance testing on each of the proxy modules based on the filtered transactions.

[0007] In some embodiments of this disclosure, the transaction monitoring module includes a filtering module and a performance testing module. The output of the filtering module is connected to the input of the performance testing module. The filtering module is used to filter transactions according to preset filtering conditions to obtain filtered transactions. The preset filtering conditions are configured to: whether the transaction message field transmitted on the bus protocol request channel matches a preset field. The performance testing module is used to perform performance testing on each of the proxy modules based on the filtered transactions.

[0008] In some embodiments of this disclosure, the performance testing module includes a selection submodule and a statistics submodule. The input of the selection submodule is connected to the output of the filtering module, and the output of the selection submodule is connected to the input of the statistics submodule. The selection submodule is used to perform selection processing on the filtered transactions to obtain a selection result, which indicates that a performance parameter to be statistically analyzed has been selected. The statistics submodule is used to obtain the parameter value of the selected performance parameter through counting and statistics.

[0009] In some embodiments of this disclosure, the statistics submodule includes: a performance statistics submodule, a mapping submodule, and a counting submodule connected sequentially. The counting submodule includes multiple counters. There are multiple performance statistics submodules, and each performance statistics submodule corresponds one-to-one with the performance parameter to be counted. The mapping submodule is used to establish a connection path between a target performance statistics submodule and a target counter. The target performance statistics submodule is one of the multiple performance statistics submodules, and the target counter is one or more of the multiple counters.

[0010] In some embodiments of this disclosure, the statistics submodule is used to obtain the parameter value of the selected performance parameter through manual counting mode or automatic counting mode.

[0011] In some embodiments of this disclosure, the transaction monitoring module further includes a configuration register module, which is connected to the filtering module and the performance testing module respectively, and is used to send configuration parameters to the filtering module and the performance testing module.

[0012] In some embodiments of this disclosure, the performance testing module includes multiple transaction trackers, each of which is used to track the time consumed from the initiation of a target transaction to the receipt of the last response of the target transaction, thereby obtaining the latency of the target transaction.

[0013] In some embodiments of this disclosure, there are multiple filtering modules and multiple performance testing modules, and each filtering module corresponds to a performance testing module. Multiple filtering modules filter the same transaction in parallel, and multiple performance testing modules perform performance tests on each proxy module in parallel based on the filtered transaction. The performance tested by different performance testing modules is different.

[0014] According to a second aspect of the present disclosure, an electronic device is provided, including any of the aforementioned system-on-a-chip.

[0015] According to a third aspect of the present disclosure, a method for operating a system-on-a-chip is provided, applicable to any of the aforementioned systems-on-a-chip, comprising: obtaining preset filtering conditions; filtering transactions according to the preset filtering conditions to obtain filtered transactions; and performing performance testing on each proxy module based on the filtered transactions.

[0016] In some embodiments of this disclosure, the performance to be tested includes latency. Performance testing is performed on each of the agent modules based on the filtered transactions, including: determining whether a transaction tracker has been requested; in response to requesting the transaction tracker, assigning the transaction tracker to a target transaction, wherein the target transaction is one of the filtered transactions; starting a timer from the time the request of the target transaction is initiated, and stopping the timer in response to receiving the last response of the target transaction, to obtain the latency of the target transaction.

[0017] In some embodiments of this disclosure, the performance to be tested includes the number of pending transactions. Performance testing is performed on each of the agent modules based on the filtered transactions, including: incrementing the count by one in response to receiving a new filtered transaction at a target time; and decrementing the count by one in response to receiving the last response of the new filtered transaction.

[0018] In some embodiments of this disclosure, the performance to be tested includes bandwidth. Performance testing is performed on each of the agent modules based on the filtered transactions, including: obtaining the total number of bytes transmitted for all the filtered transactions within a preset time period; and determining the bandwidth as the ratio of the total number of bytes transmitted to the preset time period.

[0019] In some embodiments of this disclosure, performance testing of each of the proxy modules is performed based on the filtered transactions, including: using a manual counting mode or an automatic counting mode to perform performance testing on each of the proxy modules based on the filtered transactions; wherein, a statistical time threshold is configured for the automatic counting mode, and the automatic counting mode ends in response to reaching the statistical time threshold; wherein, a start enable condition and an end enable condition are configured for the manual counting mode, and the manual counting mode starts in response to satisfying the start enable condition, and ends in response to satisfying the end enable condition.

[0020] According to a fourth aspect of the present disclosure, a chip is provided, including the above-described system-on-a-chip.

[0021] This disclosure presents a system-on-a-chip (SoC) comprising multiple agent modules and a system interconnect bus module, with each agent module connected to the system interconnect bus module. Each agent module includes a transaction monitoring module, which filters transactions according to preset filtering conditions to obtain filtered transactions. Performance testing of each agent module is then performed based on these filtered transactions. The introduction of filtering functionality in performance testing reduces the amount of transaction data, thereby improving testing efficiency. The transaction filtering function is implemented through the transaction monitoring module within the agent module, selecting valid transactions based on preset filtering conditions and filtering out a large number of irrelevant and redundant transactions, significantly reducing the amount of transaction data that needs to be collected, recorded, and parsed. This alleviates the data transmission pressure on the system interconnect bus module, reduces the data storage and processing overhead of the agent modules, and reduces the computational load in subsequent performance testing stages, improving the execution efficiency of performance testing. It is particularly suitable for large-scale SoC simulation and testing in high-concurrency transaction scenarios.

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

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0024] Figure 1 This is a schematic diagram of a system-on-a-chip according to some embodiments of the present disclosure; Figure 2 This is a schematic diagram of a transaction monitoring module according to some embodiments of the present disclosure. Figure 1 ; Figure 3 This is a schematic diagram of a transaction monitoring module according to some embodiments of the present disclosure. Figure 2 ; Figure 4 This is a schematic diagram of a transaction monitoring module according to some embodiments of the present disclosure. Figure 3 ; Figure 5 This is a schematic diagram of a transaction monitoring module according to some embodiments of the present disclosure. Figure 4 ; Figure 6 This is a schematic diagram of a transaction monitoring module according to some embodiments of the present disclosure. Figure 5 ; Figure 7This is a flowchart illustrating the implementation process of a method for operating a system-on-a-chip according to some embodiments of the present disclosure; Figure 8 This is a specific performance test flowchart illustrated according to some embodiments of the present disclosure. Figure 1 ; Figure 9 This is a specific performance test flowchart illustrated according to some embodiments of the present disclosure. Figure 2 ; Figure 10 This is a block diagram illustrating an electronic device according to an exemplary embodiment of the present disclosure.

[0025] See the following figure labels: 01. System-on-a-Chip; 10. Proxy Module; 11A, 11B, 11C. Request Proxy Module; 12A, 12B, 12C. Consistency Proxy Module; 13A, 13B, 13C. Termination Proxy Module; 110A, 110B, 110C. Transaction Monitoring Module; 120A, 120B, 120C. Transaction Monitoring Module; 130A, 130B, 130C. Transaction Monitoring Module; 20. System Interconnect Bus Module; 140. Filtering Module; 141. Filtering Submodule; 150. Performance Testing Module; 151. Selection Submodule; 152. Statistics Submodule; 153, 153A, 153B, 153C. Performance Statistics Submodule; 154. Mapping Submodule; 155. Counting Submodule; 160. Configuration Register Module; 170. Transaction Tracker. Detailed Implementation

[0026] Some embodiments of this disclosure will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. Various changes, modifications, and equivalents of the methods, apparatus, and / or systems described herein will become apparent upon understanding this disclosure. For example, the order of operations described herein is merely illustrative and is not limited to those orders set forth herein, but can be changed as will become apparent upon understanding this disclosure, except for operations that must be performed in a particular order. Furthermore, for clarity and brevity, descriptions of features known in the art may be omitted.

[0027] The embodiments described in the following examples of this disclosure are not representative of all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0028] As described in the background section, in related technologies, to test the transmission performance of a system-on-a-chip (SoC), it is usually necessary to test the performance of the proxy modules connected to the system interconnect bus. Current testing schemes are relatively inefficient. To at least overcome the above-mentioned technical deficiencies, embodiments of this disclosure provide a SoC, an electronic device, a chip, and a method of operation.

[0029] The specific implementation methods of the embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0030] Figure 1 This is a schematic diagram of a system-on-a-chip according to some embodiments of the present disclosure. For example... Figure 1 As shown, the system-on-chip 01 includes: Multiple agent modules 10 and system interconnect bus module 20, with each agent module 10 connected to the system interconnect bus module 20; Each of the agent modules 10 includes a transaction monitoring module.

[0031] The agent module 10 includes at least one of the following: Request Agent (RA), Home Agent (HA), and Completer Agent (CA). This system-on-a-chip is widely used in high-performance computing platforms such as smartphone SoCs, AI acceleration chips, and data center processors.

[0032] The transaction monitoring module is used to filter transactions according to preset filtering conditions to obtain filtered transactions, and to perform performance tests on each of the agent modules 10 based on the filtered transactions.

[0033] The preset filtering conditions are used to select target transactions for observation and discard irrelevant transactions. Specifically, the preset filtering conditions are pre-configured filtering rules used to select target transactions to be observed from all transactions. The preset filtering conditions may include at least one of the following: transaction type, master device identifier, slave device identifier, access address range, transaction priority, and transaction response status. The transaction monitoring module intercepts and filters irrelevant transactions that do not meet the conditions according to the filtering rules, and only retains the filtered transactions that meet the conditions for performance testing.

[0034] For example, Figure 1The diagram illustrates three request broker modules, three consistency broker modules, and three termination broker modules. The three request broker modules are designated as Request Broker Module 11A, Request Broker Module 11B, and Request Broker Module 11C. The three consistency broker modules are designated as Consistency Broker Module 12A, Consistency Broker Module 12B, and Consistency Broker Module 12C. The three termination broker modules are designated as Termination Broker Module 13A, Termination Broker Module 13B, and Termination Broker Module 13C. Correspondingly, there are three transaction monitoring modules: Transaction Monitoring Module 110A, Transaction Monitoring Module 110B, and Transaction Monitoring Module 110C; three transaction monitoring modules: Transaction Monitoring Module 120A, Transaction Monitoring Module 120B, and Transaction Monitoring Module 120C; and three transaction monitoring modules: Transaction Monitoring Module 130A, Transaction Monitoring Module 130B, and Transaction Monitoring Module 130C. Of course, the number of request broker modules, consistency broker modules, and termination broker modules can also be four, five, six, etc.

[0035] The request proxy module serves as the entry point for the master device connected to the on-chip system, while the termination proxy module serves as the exit point for the slave device connected to the on-chip system. The request proxy module converts the interface protocol on the master device side into a unified protocol within the system interconnect bus module. The termination proxy module performs protocol conversion between the system interconnect bus module and the slave device's memory controller, converting bus transactions into access commands recognizable by the slave device to perform read / write and cache maintenance operations. It also receives data and transaction responses from the slave device and transmits these data and responses upwards along the transaction distribution path.

[0036] In this context, "Master" refers to modules capable of proactively initiating data transfers. They can actively send read and write requests to the System Interconnect Bus (SIB) module, acting as the "brain" and "action initiator" of the entire system, and communicating with "Slave" devices through the SIB module. Master devices specifically include: Central Processing Unit (CPU), CPU clusters, Graphics Processing Unit (GPU), Digital Signal Processor (DSP), Neural-network Processing Unit (NPU), Direct Memory Access (DMA), multimedia modules, etc. Numerous heterogeneous master devices require parallel access to the shared System Cache (SLC) and external memory.

[0037] The performance tested for each of the agent modules includes at least one of the following: bandwidth size, outstanding number of pending transactions, and latency. Bandwidth size is the amount of data transmitted per unit time; outstanding number of pending transactions is the number of transactions that have been sent but have not yet received a complete response / return data; latency is the time taken for a single transaction from sending a request to receiving a response.

[0038] This disclosure describes a system-on-a-chip (SoC) comprising multiple agent modules and a system interconnect bus module, with each agent module connected to the system interconnect bus module. Each agent module includes a transaction monitoring module, which filters transactions according to preset filtering conditions to obtain filtered transactions. Performance testing of each agent module is then performed based on these filtered transactions. The introduction of filtering functionality in performance testing reduces the amount of transaction data, thereby improving testing efficiency. The transaction filtering function is implemented through the transaction monitoring module within the agent module, selecting valid transactions based on preset filtering conditions and filtering out a large number of irrelevant and redundant transactions, significantly reducing the amount of transaction data that needs to be collected, recorded, and parsed. This alleviates the data transmission pressure on the system interconnect bus module, reduces the data storage and processing overhead of the agent modules, and reduces the computational load in subsequent performance testing stages, improving the execution efficiency of performance testing. It is particularly suitable for large-scale SoC simulation and testing in high-concurrency transaction scenarios. Furthermore, it does not affect the normal transmission of bus commands, does not increase the bit width of transaction transmission, and can save the area of ​​the bus network, i.e., the SoC.

[0039] See Figure 2 The transaction monitoring module includes a filtering module 140 and a performance testing module 150, wherein the output of the filtering module 140 is connected to the input of the performance testing module 150. The filtering module 140 is used to filter transactions according to the preset filtering conditions to obtain filtered transactions. The preset filtering conditions are configured as follows: whether the transaction message field transmitted on the bus protocol request channel matches the preset field. "Matching" refers to the filtering module comparing key fields of transaction messages collected in real time on the bus protocol request channel with pre-configured preset fields. The matching method can be at least one of numerical equality comparison, bitmask comparison, or numerical range comparison. When a message field meets the preset field comparison rules, it is considered a match, and the transaction is output as a filtered transaction; otherwise, it is considered a mismatch, and the transaction is filtered out. The matching can simultaneously perform matching checks on one or more fields, including transaction ID, access address, and custom sideband fields. When multiple fields are configured, a combination of AND, OR, and OR logic can be used for the judgment.

[0040] For example, the transaction message field value is equal to a preset field value. For instance, the preset axid=0x5. Only transactions with axid=0x5 are considered a match and are retained; the rest are filtered out and discarded.

[0041] For example, the preset field also carries a mask, and only the bits that are effective with the mask are compared, ignoring the bits that are blocked by the mask. For instance, only the high 20 bits of the address are compared, while the low 12 bits are ignored, thus achieving address range or address segment filtering.

[0042] For example, for the addr address field, a match is determined by determining that the text segment is within the preset upper and lower limit range of the address.

[0043] For example, multiple fields (e.g., axid + addr + axuser) can be ANDed or ORed; a match is made only if all conditions are met, or a match is made if any one condition is met.

[0044] For example, the transaction message fields transmitted on the bus protocol request channel include the axi protocol's axid, axaddr, and axuser fields. axid represents the transaction identifier, or transaction ID field, used to uniquely identify a transaction and distinguish transactions from different master devices or initiating requests. Axi relies on axid to complete the pairing of requests and responses, supporting out-of-order response returns. axaddr represents the access address field, i.e., the starting address of the target memory / register to be accessed, the target address for read / write requests, used to specify the slave device address space to be accessed in this transaction. axuser represents a user-defined field; the Axi protocol does not specify the internal meaning of this field, leaving it to chip design to define, used to carry additional sideband information with the address message; for example, transmitting extended information such as security flags, permissions, transaction types, and stream flags. The protocol itself does not parse axuser; the master and slave devices define their own parsing rules.

[0045] For example, the transaction message fields transmitted on the bus protocol request channel include the txnid, addr, and rsvdc fields of the CHI protocol. txnid represents the transaction identifier, used to uniquely identify a CHI bus transaction, enabling transaction pairing between request messages and response / data messages, and distinguishing multiple concurrent transmission transactions. addr represents the access address field, characterizing the target access start address corresponding to this transaction. rsvdc represents a user-defined field reserved for the protocol; the CHI protocol itself does not enforce the definition or parsing of this field, allowing the chip design end to carry custom sideband auxiliary information.

[0046] For example, the transaction message fields transmitted on the bus protocol request channel also include transaction message fields for other types of protocols besides the AXI and Chi protocols, such as the ACE protocol, the NOC protocol, packet-based transmission protocols, etc., which have strong reusability.

[0047] For example, the filtering module can be implemented using a filter. The filter includes digital logic circuitry, such as comparators, AND gates, OR gates, etc.

[0048] The performance testing module 150 is used to perform performance tests on each of the agent modules 10 based on the filtered transactions.

[0049] By applying this publicly available solution, performance statistics for all bus transactions are no longer performed. Irrelevant transactions are filtered out beforehand, reducing the data processing load of the performance testing module, saving hardware logic, and lowering power consumption. By configuring different preset fields, the transactions to be observed (specific txnid / axid, specific address ranges, specific user-defined fields) can be flexibly selected to adapt to different business scenario testing needs. Furthermore, performance statistics are performed based on the filtered target transactions, eliminating noise interference from irrelevant transactions. The test results closely reflect actual business conditions, facilitating accurate assessment and location of performance bottlenecks in each agent module.

[0050] See Figure 3 The performance testing module 150 includes a selection submodule 151 and a statistics submodule 152. The input of the selection submodule 151 is connected to the output of the filtering module 140, and the output of the selection submodule 151 is connected to the input of the statistics submodule 152. The selection submodule 151 is used to perform selection processing on the filtered transactions to obtain a selection result, wherein the selection result indicates that a performance parameter to be statistically analyzed has been selected; for example, bandwidth size is selected; for example, outstanding number of pending transactions is selected; for example, latency is selected.

[0051] The statistics submodule 152 is used to obtain the parameter value of the selected performance parameter through counting statistics.

[0052] The selection submodule allows users to choose the performance parameters to be observed from a variety of options. The statistics submodule then performs counting statistics based on the selected parameters and filtered transactions. This eliminates the need to perform calculations on all performance parameters simultaneously, reducing the computational logic and hardware overhead within the statistics submodule. It also supports flexible switching between different observation dimensions such as bandwidth, number of pending transactions, and latency, enabling multi-dimensional configurable performance statistics for the proxy module. This enhances the flexibility of performance testing and allows for the output of performance parameter values ​​as needed, facilitating targeted analysis of various performance metrics of the proxy module.

[0053] See Figure 4 The statistics submodule 152 includes a performance statistics submodule 153, a mapping submodule 154, and a counting submodule 155 connected sequentially. The counting submodule 155 includes multiple counters. There are multiple performance statistics submodules 153, and each performance statistics submodule 153 corresponds one-to-one with the performance parameter to be counted. The mapping submodule 154 is used to establish a connection path between the target performance statistics submodule 153 and the target counter. The target performance statistics submodule 153 is one of the multiple performance statistics submodules 153, and the target counter is one or more of the multiple counters.

[0054] Multiple performance statistics submodules independently correspond to different performance parameters, and the calculation and processing of each parameter are isolated from each other. A mapping submodule dynamically establishes a connection path between the target performance statistics submodule and the target counter within the counting submodule, allowing for flexible allocation of one or more counter resources for the currently selected performance parameter. This eliminates the need for statically and exclusively configuring a dedicated counter for each performance parameter, enabling the sharing and reuse of counter hardware resources, reducing the number of counters, and saving hardware logic resources. Simultaneously, it supports flexible scheduling of counters based on parameter statistics requirements, adapting to the counting needs of different performance parameters and improving hardware resource utilization.

[0055] In some embodiments of this disclosure, the statistics submodule is used to obtain the parameter value of the selected performance parameter through a manual counting mode or an automatic counting mode. The automatic counting mode is configured with a statistical time threshold, and the automatic counting mode ends upon reaching the statistical time threshold. The manual counting mode is configured with a start enable condition and an end enable condition, and the manual counting mode starts upon satisfying the start enable condition and ends upon satisfying the end enable condition.

[0056] For example, the statistical time threshold can be set according to the transaction burst cycle, business frame cycle, and business cycle cycle of the business scenario. If the business is periodic, the statistical time threshold can be configured as an integer multiple of the business cycle to ensure that the statistical window can cover the complete business cycle and avoid distortion of statistical results caused by only capturing a part of the business segment.

[0057] For example, if a steady-state performance evaluation is performed, the statistical time threshold is set relatively high to collect the average bandwidth, average latency, and average number of pending transactions under long-term steady-state traffic; if a short-term peak stress test is performed, the statistical time threshold is set relatively low to capture the peak parameters within the burst traffic window.

[0058] For example, the statistical time threshold needs to match the system clock granularity, and the maximum suspendable duration of a transaction can be combined with the internal cache depth of the proxy module and the system sampling clock frequency. The threshold cannot be less than the minimum statistical time granularity.

[0059] For example, the larger the statistical time threshold, the more samples are collected, and the closer the statistical results are to the true average level, but the counter bit width needs to be increased, and the hardware overhead increases; if the statistical time threshold is too small, the sample size is insufficient, and the statistical results are highly random, so a balance needs to be struck between statistical accuracy and counter hardware resources.

[0060] For example, the start enable condition includes writing to the software control register, which will count the start position as 1; the end enable condition includes writing to the software control register, which will count the stop position as 1.

[0061] For example, the start enable conditions include detecting a high system service start signal, a proxy module exiting and resetting, and a valid traffic enable signal; the end enable conditions include a high service stop signal, a proxy module entering low-power sleep mode, and a valid traffic stop signal.

[0062] For example, the start enable condition includes the number of outstanding pending transactions within the agent module rising above a preset threshold, triggering the start of statistics for specifically observing performance during the congestion phase; the end enable condition includes the number of pending transactions falling back below the preset threshold, ending the statistics and only capturing data from the window in which congestion occurred.

[0063] The statistics submodule allows users to choose between manual or automatic counting modes to perform performance parameter statistics. Automatic counting mode uses preset statistical time thresholds to achieve automatic statistics for a fixed duration, automatically ending the statistics once the threshold is reached, suitable for performance testing scenarios with fixed observation windows. Manual counting mode allows for flexible control of the start and stop of statistics via start and stop conditions, matching the start and end times of actual business events. The two counting modes work together to achieve both scheduled automatic statistics and event-triggered statistics for specific business event segments, enriching the control methods for performance statistics, adapting to diverse testing needs, and improving the flexibility and scenario adaptability of performance testing.

[0064] See Figure 5 The transaction monitoring module further includes a configuration register module 160, which is connected to the filtering module 140 and the performance testing module 150 respectively, and is used to send configuration parameters to the filtering module 140 and the performance testing module 150.

[0065] The configuration register module centrally distributes various configuration parameters to both the filtering and performance testing modules, enabling centralized configuration management of preset filtering conditions and performance testing parameters. The software only needs to access the same set of configuration registers to configure preset filtering conditions, performance statistics modes, and threshold parameters, eliminating the need for separate register accesses to the two modules and simplifying the software configuration process. Simultaneously, it ensures that configuration parameters are distributed synchronously between the filtering and performance testing modules, reducing statistical errors caused by configuration asynchrony and improving the overall reliability and configuration efficiency of transaction monitoring.

[0066] See Figure 6 The performance testing module 150 includes multiple transaction trackers 170, each of which is used to track the time consumed from the initiation of a target transaction to the receipt of the last response of the target transaction, thereby obtaining the latency of the target transaction. Figure 6 There are M transaction trackers in the middle (170). Each transaction tracker corresponds to one transaction.

[0067] By setting up multiple independent transaction trackers, each corresponding to a target transaction, multiple parallel target transactions can be tracked independently simultaneously. The system accurately captures the initiation time of each transaction request and the return time of the last response, calculating the complete end-to-end latency of a single transaction. It supports latency acquisition in multi-transaction concurrent scenarios on the bus, preventing timing errors caused by out-of-order transactions or fragmented response returns, thus improving the accuracy of transaction latency measurement and enabling the simultaneous acquisition of latency data for multiple concurrent transactions.

[0068] In some embodiments of this disclosure, there are multiple filtering modules and multiple performance testing modules, and each filtering module corresponds to a performance testing module. Multiple filtering modules filter the same transaction in parallel, and multiple performance testing modules perform performance tests on each proxy module in parallel based on the filtered transaction. The performance tested by different performance testing modules is different.

[0069] Multiple pairs of filtering and performance testing modules are configured to perform multi-channel filtering and performance statistics in parallel on the same group of bus transactions. Different performance testing modules are responsible for collecting different types of performance metrics. There is no need to capture and replay bus transactions multiple times; a single transaction stream input can simultaneously obtain multi-dimensional performance data, enabling parallel measurement of multiple metrics. Each group of links is independent, and metric collection does not interfere with each other, improving performance testing efficiency. Simultaneous statistics on multiple performance dimensions such as latency, throughput, and concurrent transactions can be completed simultaneously.

[0070] See Figure 6The transaction monitoring module includes a filtering module 140, a selection submodule 151, a performance statistics submodule 153A, a performance statistics submodule 153B, a performance statistics submodule 153C, a mapping submodule 154, a counting submodule 155, and a configuration register module 160.

[0071] The filtering module 140 includes multiple filtering sub-modules 141. These sub-modules can execute multiple sets of preset filtering condition judgments in parallel. The preset filtering conditions for each sub-module can be configured individually, meaning different sub-modules can execute different preset filtering conditions. Ultimately, an event trigger signal (Event_trig) is output. This enables parallel statistics on bandwidth, number of pending transactions, and latency. In other words, multi-condition parallel processing does not increase bus path latency. Upon hitting a target transaction, an event trigger signal is output for the backend module to initiate transaction tracking, offering flexible configuration.

[0072] Performance statistics submodule 153A corresponds to latency, performance statistics submodule 153B corresponds to outstanding pending transactions, and performance statistics submodule 153C corresponds to bandwidth size. Performance statistics submodule 153A includes M transaction trackers 170; counting submodule 155 includes N counters. Mapping submodule 154 implements the mapping between the counters in performance statistics submodule 153A and counting submodule 155, the mapping between performance statistics submodule 153B and counting submodule 155, and the mapping between performance statistics submodule 153C and counting submodule 155. If the number of counters in counting submodule 155 is sufficient, M counters can be configured for the M transaction trackers 170.

[0073] For example, the outstanding number of pending transactions and latency are statistically analyzed in the form of a bar chart. Therefore, based on the number of intervals on the horizontal axis of the bar chart, the performance statistics submodules 153A and 153B are mapped to multiple counters.

[0074] In addition, manual and automatic counting modes are configured through software. In manual counting mode, an event counter (event_counter) is used, while in automatic counting mode, a time counter (timer_counter) is used.

[0075] The following are embodiments of the working method of this disclosure, which can be applied to the system-on-a-chip embodiments of this disclosure. For details not disclosed in the embodiments of the working method of this disclosure, please refer to the system-on-a-chip embodiments of this disclosure.

[0076] like Figure 7 The diagram illustrates a method for operating a system-on-a-chip (SoC) according to an embodiment of this disclosure. This method is applicable to any SoC provided in the above embodiments and includes the following steps.

[0077] In step S702, preset filtering conditions are obtained; In step S704, the transactions are filtered according to the preset filtering conditions to obtain the filtered transactions; In step S706, performance tests are performed on each of the agent modules based on the filtered transactions.

[0078] The on-chip system operation method disclosed herein involves obtaining preset filtering conditions, filtering transactions according to these conditions to obtain filtered transactions, and performing performance tests on each of the agent modules based on the filtered transactions. The introduction of filtering functionality in performance testing reduces the amount of transaction data, thereby improving testing efficiency. By selecting valid transactions based on preset filtering conditions and filtering out a large number of irrelevant and redundant transactions, the amount of transaction data that needs to be collected, recorded, and parsed is significantly reduced. This improves the execution efficiency of performance testing and is particularly suitable for large-scale on-chip system simulation and testing in high-concurrency transaction scenarios.

[0079] In some embodiments of this disclosure, the performance to be tested includes latency. Step S704: Perform performance testing on each of the agent modules based on the filtered transactions, including: Step S7042: Determine whether a transaction tracker has been successfully requested; Step S7044: In response to obtaining the transaction tracker, the transaction tracker is assigned to the target transaction, wherein the target transaction is one of the filtered transactions; Step S7046: Start timing from the time the request for the target transaction is initiated, and stop timing in response to receiving the last response of the target transaction to obtain the delay of the target transaction.

[0080] By requesting a transaction tracker and assigning it to a filtered target transaction, timing begins from the moment the target transaction request is initiated and stops when the last response of the target transaction is received, thus obtaining the complete latency of the target transaction. On the one hand, this can fully cover the entire processing cycle of a transaction from its inception to the return of all responses, obtaining the true end-to-end latency of transactions under the proxy module and improving the accuracy of performance testing. On the other hand, the transaction tracker is assigned to selected target transactions as needed, without needing to enable tracking for all transactions, saving limited on-chip hardware tracing resources and reducing performance interference to the proxy module under test during the testing process.

[0081] In some embodiments of this disclosure, the performance to be tested includes the number of pending transactions. Step S704: Perform performance testing on each of the proxy modules based on the filtered transactions, including: Step S7043: In response to receiving new filtered transactions at the target time, increment the counter value by one; Step S7045: In response to receiving the last response of the new filtered transaction, decrement the count value by one.

[0082] When a new filtered transaction is generated at the target time, the count is incremented by one, and when the last response of the transaction is received, the count is decremented by one, thus obtaining the number of pending transactions for the proxy module. On the one hand, using the return of all responses for a transaction as the condition for transaction completion avoids exiting the counting before all transactions are processed, ensuring the accuracy of the pending transaction count. On the other hand, counting is only performed on filtered transactions, reducing counting processing overhead and allowing for targeted assessment of the congestion and queuing status of the proxy module under specific business traffic. At the same time, this transaction completion determination rule is consistent with latency measurement, ensuring data consistency among multiple performance test indicators.

[0083] In some embodiments of this disclosure, the performance to be tested includes bandwidth. Step S704: Perform performance testing on each of the agent modules based on the filtered transactions, including: Step S7047: Obtain the total number of bytes transmitted for all filtered transactions within a preset time period; Step S7049: Determine the bandwidth as the ratio of the total number of transmitted bytes to the preset time period.

[0084] By obtaining the total number of bytes transmitted in filtered transactions within a preset time period, the ratio of the total number of bytes transmitted to the preset time period is determined as the bandwidth. In this way, byte statistics based on filtered transactions can be used to determine the actual throughput bandwidth of the target business traffic through the proxy module. The use of a fixed time window ratio calculation method ensures a consistent statistical standard for bandwidth indicators, facilitating horizontal performance comparisons across different proxy modules and different business scenarios. In some embodiments of this disclosure, performance testing is performed on each of the proxy modules based on the filtered transactions, including: The performance of each of the agent modules is tested based on the filtered transactions, using either manual or automatic counting mode. The automatic counting mode is configured with a statistical time threshold, and the automatic counting mode ends in response to reaching the statistical time threshold. The manual counting mode is configured with a start enable condition and an end enable condition. The manual counting mode starts in response to the start enable condition being met, and ends in response to the end enable condition being met.

[0085] This disclosure also relates to a specific method for operating a system-on-a-chip, which is applicable to... Figure 6 The transaction monitoring module shown includes the following method: Step 1: Each preset filter condition supports fuzzy matching based on bit masking. The matching logic for the preset filter condition is implemented as follows: filter_xxxi_match[filter_idx] =(cfg_xxxi_bitmask[filter_idx] & req_xxxi)==(cfg_xxxi_bitmask[filter_idx] & cfg_xxxi[filter_idx]).

[0086] filter_match[filter_idx]=filter_xxx0_match[filter_idx]&filter_xxx1_match[filter_idx]&filter_xxx2_match[filter_idx]&filter_xxxN_match[filter_idx].

[0087] The number of filters (or filter sub-modules) in the Transaction monitor module is configurable. `filter_idx` represents the filter number; `filter_xxxi_match` indicates that the i-th segment of the filter matched successfully; `cfg_xxx_bitmask` represents the bit masking signal for the xxx segment configured by the filter, with 0 indicating masking; `req_xxx` represents the segment information of the request channel transmitted by the protocol. `cfg_xxx` indicates that the preset filtering condition is met when the xxx segment matches this value. `filter_match` indicates that all preset filtering conditions are met. `filter_xxx0_match ~filter_xxxN_match` indicates that the filter matched successfully from segment 0 to N.

[0088] Step 2: Implement statistics on bandwidth, latency, and the number of pending transactions.

[0089] 1) Implementation of bandwidth statistics: When the proxy module receives a request from the upstream, the filtering submodule 141 is configured in bandwidth statistics mode. Different protocols calculate the bandwidth of this transaction based on the information carried in the request. After the filtering conditions of the filtering submodule are met, the bandwidth is accumulated on the counter by selecting submodule 151 as the step size. When the statistics are completed, the value of the counter is read, and the average bandwidth of the statistical period is obtained by dividing the value of the counter by the statistical time.

[0090] 2) For the implementation of delay statistics, please refer to [link / reference]. Figure 8 .

[0091] For latency statistics, to save space and support sampling statistics, the number of samples (i.e., the M value in transaction tracker 170) is configurable. When the number of samples has not been reached, when the proxy module receives a request from the upstream, after meeting the filtering conditions of the filtering submodule 141, the performance statistics submodule 153A starts counting. Counting stops when the last response of the corresponding transaction is received. The counter value is compared with the configured interval threshold, and the comparison result is used as the statistical counter event for the corresponding interval, incrementing the counter by 1 and releasing a sampling slot, i.e., transaction tracker 170. When the configured number of samples has been reached, requests received by the proxy module are not counted. Furthermore, the counting mode includes manual counting mode and automatic counting mode. The latency statistics are represented in the form of a bar chart. This provides a more intuitive presentation of the performance parameter statistics over a period of time.

[0092] 3) For the implementation of the pending transaction count, please refer to [link / reference]. Figure 9 .

[0093] When the proxy module receives a request from the upstream, if the filtering conditions of the filtering submodule 141 are met, the count value of the performance statistics submodule 153B is incremented. When the last response of the corresponding transaction is received, the count value of the performance statistics submodule 153B is decremented. Simultaneously, the current value of the performance statistics submodule 153B is compared with the configured interval threshold. The comparison result is used as the event counter for the corresponding interval, incrementing the counter by 1. Furthermore, the counting mode includes manual counting mode and automatic counting mode. The statistical results of the number of pending transactions are represented in the form of a bar chart. This provides a more intuitive presentation of the statistical results of performance parameters over a period of time.

[0094] Some embodiments of this disclosure also illustrate a chip, including the system-on-a-chip illustrated in embodiments of this disclosure.

[0095] Some embodiments of this disclosure also illustrate an electronic device that includes any of the system-on-a-chip described above. The electronic device may be a smartphone, tablet computer, laptop computer, television, smart wearable device, game console, etc.

[0096] Figure 10 This is a block diagram illustrating an electronic device according to an exemplary embodiment of the present disclosure. For example, device 1000 may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness device, personal digital assistant, etc.

[0097] Reference Figure 10The device 1000 may include one or more of the following components: a processing component 1002, a memory 1004, a power supply component 1006, a multimedia component 1008, an audio component 1010, an input / output (I / O) interface 1012, a sensor component 1014, and a communication component 1016.

[0098] Processing component 1002 typically controls the overall operation of device 1000, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 1002 may include one or more processors 1020 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 1002 may include one or more modules to facilitate interaction between processing component 1002 and other components. For example, processing component 1002 may include a multimedia module to facilitate interaction between multimedia component 1008 and processing component 1002.

[0099] Memory 1004 is configured to store various types of data to support the operation of device 1000. Examples of this data include instructions for any application or method operating on device 1000, contact data, phonebook data, messages, pictures, videos, etc. Memory 1004 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0100] Power supply component 1006 provides power to various components of device 1000. Power supply component 1006 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to device 1000.

[0101] The multimedia component 1008 includes a screen that provides an output interface between the device 1000 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, the multimedia component 1008 includes a front-facing camera and / or a rear-facing camera. When the device 1000 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0102] Audio component 1010 is configured to output and / or input audio signals. For example, audio component 1010 includes a microphone (MIC) configured to receive external audio signals when device 1000 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 1004 or transmitted via communication component 1016. In some embodiments, audio component 1010 also includes a speaker for outputting audio signals.

[0103] I / O interface 1012 provides an interface between processing component 1002 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0104] Sensor assembly 1014 includes one or more sensors for providing state assessments of various aspects of device 1000. For example, sensor assembly 1014 may detect the on / off state of device 1000, the relative positioning of components such as the display and keypad of device 1000, changes in the position of device 1000 or a component of device 1000, the presence or absence of user contact with device 1000, the orientation or acceleration / deceleration of device 1000, and temperature changes of device 1000. Sensor assembly 1014 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 1014 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 1014 may also include an accelerometer, a gyroscope, a magnetometer, a pressure sensor, or a temperature sensor.

[0105] Communication component 1016 is configured to facilitate wired or wireless communication between device 1000 and other devices. Device 1000 can access wireless networks based on communication standards, such as WiFi, 3G, 4G, 5G, other communication standards, or combinations thereof. In some embodiments of this disclosure, communication component 1016 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In some embodiments of this disclosure, communication component 1016 further includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0106] In some embodiments of this disclosure, the device 1000 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components.

[0107] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0108] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A system-on-a-chip, characterized in that, include: Multiple agent modules and a system interconnect bus module, wherein each agent module is connected to the system interconnect bus module; Each of the aforementioned proxy modules includes a transaction monitoring module. The transaction monitoring module is used to filter transactions according to preset filtering conditions to obtain filtered transactions, and to perform performance tests on each of the agent modules based on the filtered transactions.

2. The system-on-a-chip according to claim 1, characterized in that, The transaction monitoring module includes: The system includes a filtering module and a performance testing module, with the output of the filtering module connected to the input of the performance testing module. The filtering module is used to filter transactions according to the preset filtering conditions to obtain filtered transactions. The preset filtering conditions are configured as follows: whether the transaction message field transmitted on the bus protocol request channel matches the preset field. The performance testing module is used to perform performance tests on each of the agent modules based on the filtered transactions.

3. The system-on-a-chip according to claim 2, characterized in that, The performance testing module includes a selection submodule and a statistics submodule. The input of the selection submodule is connected to the output of the filtering module, and the output of the selection submodule is connected to the input of the statistics submodule. The selection submodule is used to perform selection processing on the filtered transactions to obtain a selection result, wherein the selection result indicates that a performance parameter to be statistically analyzed has been selected. The statistics submodule is used to obtain the parameter values ​​of the selected performance parameters through counting and statistics.

4. The system-on-a-chip according to claim 3, characterized in that, The statistics submodule includes: The performance statistics submodule, the mapping submodule, and the counting submodule are connected sequentially. The counting submodule includes multiple counters. There are multiple performance statistics submodules, and each performance statistics submodule corresponds one-to-one with the performance parameter to be counted. The mapping submodule is used to establish a connection path between the target performance statistics submodule and the target counter, wherein the target performance statistics submodule is one of a plurality of performance statistics submodules, and the target counter is one or more of a plurality of counters.

5. The system-on-a-chip according to claim 3, characterized in that, The statistics submodule is used to obtain the parameter value of the selected performance parameter through manual counting mode or automatic counting mode.

6. The system-on-a-chip according to claim 2, characterized in that, The transaction monitoring module also includes: A configuration register module is connected to both the filtering module and the performance testing module, and is used to send configuration parameters to both modules.

7. The system-on-a-chip according to claim 2, characterized in that, The performance testing module includes multiple transaction trackers. Each of the aforementioned transaction trackers is used to track the time consumed from the initiation of a target transaction to the receipt of the last response to the target transaction, thereby obtaining the delay of the target transaction.

8. The system-on-a-chip according to claim 2, characterized in that, There are multiple filtering modules and multiple performance testing modules, and each filtering module corresponds to a performance testing module. Multiple filtering modules filter the same transactions in parallel, and multiple performance testing modules perform performance tests on each proxy module in parallel based on the filtered transactions, wherein different performance testing modules test different performance.

9. An electronic device, characterized in that, Includes the system-on-a-chip as described in any one of claims 1 to 8.

10. A method for operating a system-on-a-chip, characterized in that, The on-chip system applicable to any one of claims 1 to 8 includes: Get the preset filter conditions; The transactions are filtered according to the preset filtering conditions to obtain the filtered transactions; Performance tests are performed on each agent module based on the filtered transactions.

11. The method of operating a system-on-a-chip according to claim 10, characterized in that, The performance to be tested includes latency. Performance tests are performed on each of the agent modules based on the filtered transactions, including: Determine whether a transaction tracker has been successfully requested; In response to obtaining the transaction tracker, the transaction tracker is assigned to a target transaction, wherein the target transaction is one of the filtered transactions; The timer starts from the moment the request for the target transaction is initiated and stops when the last response to the target transaction is received, thus obtaining the delay of the target transaction.

12. The method of operating a system-on-a-chip according to claim 10, characterized in that, The performance to be tested includes the number of pending transactions. Performance tests are performed on each of the agent modules based on the filtered transactions, including: In response to receiving a new filtered transaction at the target time, the counter value is incremented by one; In response to receiving the last response to the new filtered transaction, the count is decremented by one.

13. The method of operating a system-on-a-chip according to claim 10, characterized in that, The performance to be tested includes bandwidth. Performance tests are performed on each of the agent modules based on the filtered transactions, including: Obtain the total number of bytes transmitted for all filtered transactions within a preset time period; The bandwidth is determined by the ratio of the total number of bytes transmitted to the preset time period.

14. The method of operating a system-on-a-chip according to claim 10, characterized in that, Performance tests are performed on each of the agent modules based on the filtered transactions, including: The performance of each of the agent modules is tested based on the filtered transactions, using either manual or automatic counting mode. The automatic counting mode is configured with a statistical time threshold, and the automatic counting mode ends in response to reaching the statistical time threshold. The manual counting mode is configured with a start enable condition and an end enable condition. The manual counting mode starts in response to the start enable condition being met, and ends in response to the end enable condition being met.

15. A chip, characterized in that, Includes the system-on-a-chip as described in any one of claims 1 to 8.

Images