Method, device, electronic equipment and computer program product for performance monitoring of a die interconnect system

Abstract

The application provides a performance monitoring method and device of a die interconnection system, electronic equipment and computer program product, the system comprising a local die and a remote die. The method first acquires a sending time of target flow control unit information by a synchronization counter in the local die and a receiving time of the target flow control unit information by a synchronization counter in the remote die when the local die sends the target flow control unit information to the remote die. Then, the method determines a data transmission delay between the local die and the remote die according to a calibration delay between the local die and the remote die, the sending time of the target flow control unit information and the receiving time of the target flow control unit information. Thus, the accurate sending and receiving time of the same flow control unit is acquired, and the calibration delay is determined in advance, so that the data transmission delay of die interconnection can be directly and accurately measured in the D2D system.

Description

Technical Field

[0001] This application belongs to the field of chip technology, and in particular relates to a performance monitoring method, apparatus, electronic device and computer program product for a die interconnect system. Background Technology

[0002] Currently, in the field of large-scale chip design, the multi-die architecture based on chiplet technology has been widely adopted. This architecture integrates multiple dies with potentially different functions and processes into a complete system through system-in-package (SiP). Against this backdrop, Universal Chiplet Interconnect Express (UCIe) has become the mainstream protocol standard for implementing die-to-die (D2D) interconnect technology.

[0003] In related technologies, there are significant shortcomings in the performance monitoring methods for UCIe-based D2D systems. While electronic design automation (EDA) simulation tools can be used to obtain relevant data during the pre-silicon functional verification phase, the UCIe standard itself does not define corresponding performance monitoring methods for the post-silicon testing phase. This makes it difficult for testers to directly and accurately obtain the true performance of the D2D system when faced with a near-"black box" chip. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and computer program product for monitoring the performance of a die interconnect system, which can directly and accurately monitor the performance of the D2D system.

[0005] A first aspect of this application provides a performance monitoring method for a die interconnect system, the die interconnect system including a local die and a remote die, the performance of the die interconnect system including data transmission latency, the method including: when the local die sends target flow control unit information to the remote die, obtaining the transmission time of the target flow control unit information through a synchronization counter in the local die, and obtaining the reception time of the target flow control unit information through a synchronization counter in the remote die; determining the data transmission latency between the local die and the remote die based on a predetermined calibration delay between the local die and the remote die, the transmission time of the target flow control unit information, and the reception time of the target flow control unit information.

[0006] In the technical solution of this application, by obtaining the precise transmission and reception times of the same flow control unit (Flit) and combining them with a predetermined calibration delay, the data transmission delay of the inter-chip interconnection can be directly and accurately measured within the D2D system, thereby improving the efficiency of performance analysis and facilitating system performance optimization.

[0007] Optionally, in one possible implementation of the first aspect, determining the data transmission delay between the local and remote dies based on a pre-determined calibration delay, the transmission time of the target flow control unit information, and the reception time of the target flow control unit information includes: when the reception time of the target flow control unit information is greater than the transmission time of the target flow control unit information, subtracting the transmission time of the target flow control unit information from the reception time, and then subtracting the calibration delay to obtain the value, which is determined as the data transmission delay between the local and remote dies; when the reception time of the target flow control unit information is less than the transmission time of the target flow control unit information, subtracting the reception time of the target flow control unit information from the preset maximum value of the synchronization counter, adding the transmission time of the target flow control unit information, adding 1, and then subtracting the calibration delay to obtain the value, which is determined as the data transmission delay between the local and remote dies. Therefore, by distinguishing whether the counter overflows and returns to zero during delay calculation and employing different time difference calculation strategies, the calculation result of the data transmission delay is ensured to be accurate and reliable at any operating time.

[0008] Optionally, in another possible implementation of the first aspect, before determining the data transmission delay between the local die and the remote die based on the predetermined calibration delay between the local die and the remote die, the transmission time of the target flow control unit information, and the reception time of the target flow control unit information, the method further includes: resetting the synchronization counters of the local die and the remote die to zero and setting a target lock count value; starting the synchronization counter of the local die through the local die and sending a counter start command to the remote die, so that the remote die starts its corresponding synchronization counter upon receiving the counter start command; stopping the counting when the synchronization counter of the remote die reaches the target lock count value and sending a reply command to the local die, so that the local die determines its current corresponding synchronization counter value upon receiving the reply command; and determining the calibration delay between the local die and the remote die based on the target lock count value and the current corresponding synchronization counter value of the local die. Thus, by measuring the calibration delay through the complete counter synchronization start, lock, and response mechanism described above, the inherent communication overhead of the control path can be accurately quantified and eliminated, thereby improving the accuracy of the final data transmission delay.

[0009] Optionally, in another possible implementation of the first aspect, determining the calibration delay between the local die and the remote die based on the target lock count value and the current synchronization counter value of the local die includes: if the current synchronization counter value of the local die is greater than the target lock count value, dividing the difference between the current synchronization counter value of the local die and the target lock count value by 2 to obtain the calibration delay between the local die and the remote die; if the current synchronization counter value of the local die is less than the target lock count value, subtracting the target lock count value from the preset maximum value of the synchronization counter, adding the current synchronization counter value of the local die, adding 1, and then dividing the resulting value by 2 to obtain the calibration delay between the local die and the remote die. Therefore, by considering and processing the case of counter overflow to zero in the calculation of the calibration delay, the measurement accuracy of the calibration delay itself is ensured to be unaffected by the counter bit width limitation, laying a solid foundation for high-precision delay calculation.

[0010] Optionally, in another possible implementation of the first aspect, the performance of the aforementioned die interconnect system also includes bandwidth utilization. The method further includes: acquiring at least one flow control unit information transmitted or received by the local die within a preset time period; determining the busy count and idle count of the local die within the preset time period based on the transmission or reception time corresponding to the at least one flow control unit information; and determining the bandwidth utilization corresponding to the local die based on the busy count and idle count of the local die within the preset time period. Thus, by directly counting the number of busy and idle cycles at the interface level, rather than relying on software simulation or estimation, the actual bandwidth utilization of the link can be measured in real time and accurately, providing crucial data for system performance bottleneck analysis.

[0011] Optionally, in another possible implementation of the first aspect, the method further includes: reading the busy and idle counts of the remote die via a sideband from the local die, and storing the busy and idle counts of the remote die; or, storing the busy and idle counts of the remote die via the remote die itself. Thus, by providing two storage schemes for remote performance data—unified storage via a sideband or direct remote storage—flexible solutions are provided for different system architectures and performance requirements.

[0012] Optionally, in another possible implementation of the first aspect, the above-mentioned die interconnect system performance also includes a bandwidth allocation ratio, and the method further includes: acquiring flow control unit information of multiple protocols transmitted or received by the local die within a preset time period; determining the flow control unit information count value corresponding to each protocol based on the flow control unit information of the multiple protocols; and determining the bandwidth allocation ratio corresponding to the local die based on the flow control unit information count value corresponding to each protocol. Thus, by counting the number of flow control units according to protocol type, the allocation ratio of different protocol data streams in the total bandwidth can be accurately calculated, providing a direct basis for analyzing and optimizing system resource scheduling in multi-protocol mixed transmission scenarios.

[0013] A second aspect of this application provides a performance monitoring unit (PMU) for a die interconnect system. The die interconnect system includes a local die and a remote die. The performance of the die interconnect system includes data transmission latency. The device includes: a data statistics module, used to obtain the transmission time of the target flow control unit information through a synchronization counter in the local die and the reception time of the target flow control unit information through a synchronization counter in the remote die when the local die sends target flow control unit information to the remote die; and a performance calculation and storage module, used to determine the data transmission latency between the local die and the remote die based on a predetermined calibration delay between the local die and the remote die, the transmission time of the target flow control unit information, and the reception time of the target flow control unit information.

[0014] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the performance monitoring method of the die interconnect system described in the first aspect.

[0015] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the performance monitoring method for the die interconnect system described in the first aspect.

[0016] The fifth aspect of this application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the performance monitoring method of the die interconnect system described in the first aspect.

[0017] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of a D2D system based on Chiplet technology;

[0020] Figure 2 This is a schematic diagram of a D2D scene;

[0021] Figure 3 This is a schematic flowchart of a performance monitoring method for a die interconnect system provided in an embodiment of this application;

[0022] Figure 4 This is a schematic diagram of a D2D scene provided in an embodiment of this application;

[0023] Figure 5 This is a schematic diagram of the calibration process provided in the embodiments of this application;

[0024] Figure 6 This is a schematic diagram illustrating the performance data acquisition provided in an embodiment of this application;

[0025] Figure 7 This is a schematic diagram of performance computing storage provided in an embodiment of this application;

[0026] Figure 8 This is a schematic diagram of the structure of a performance monitoring device for a die interconnect system provided in an embodiment of this application;

[0027] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0029] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0030] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0031] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0032] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0033] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0034] It should be understood that the sequence number of each step in this embodiment does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application embodiment.

[0035] In related technologies, see, for example, Figure 1 The diagram shows a D2D system based on Chiplet technology. This architecture integrates multiple dies with potentially different functions and processes through system-level packaging (SLP) using D2D technology. These dies are then laid flat or stacked on a substrate and packaged together to form a large system-level chip, constituting a complete system. UCIe is the mainstream interconnect protocol between dies. In this application, the term "chip" refers to the fully functional packaged whole, while "Chiplet" and "Die" refer to a specific type of die or bare chip within the chip package that fulfills a particular function.

[0036] The UCIe standard adopts a layered protocol architecture, consisting of three layers from top to bottom: Protocol Layer, Adapter Layer, and Physical Layer. The Protocol Layer connects to the System on Chip (SoC) and is typically connected to a Network on Chip (NoC). It supports standard protocols such as Advanced Dextensible Interface (AXI), Coherent Hub Interface (CHI), Credited eXtensible Stream (CXS), Peripheral Component Interconnect Express (PCIe) / Compute Express Link (CXL), and can also support custom streaming protocols.

[0037] Figure 2 A schematic diagram of a D2D scene is shown, such as Figure 2 As shown, the protocol layer and the adaptation layer communicate via the Flow Control Unit-aware die-to-die interface (FDI), while the adaptation layer and the physical layer are connected via the raw die-to-die interface (RDI). UCIe supports the transmission of multiple protocols on the same link, with the adaptation layer responsible for bandwidth allocation.

[0038] However, current performance monitoring methods for UCIe-based D2D systems are significantly inadequate. While data can be obtained through electronic design automation (EDA) simulation tools during the pre-silicon functional verification phase, the UCIe standard itself does not define corresponding performance monitoring methods for the post-silicon testing phase. This makes it difficult for testers to directly and accurately obtain the true performance of the D2D system when faced with a near-"black box" chip.

[0039] In view of this, embodiments of this application provide a performance monitoring method, apparatus, electronic device, and computer program product for a die interconnect system. First, when a target flow control unit (FCU) information is sent from a local die to a remote die, the transmission time of the FCU information is obtained using a synchronization counter in the local die, and the reception time of the FCU information is obtained using a synchronization counter in the remote die. Then, based on a predetermined calibration delay between the local and remote dies, the transmission time of the FCU information, and the reception time of the FCU information, the data transmission delay between the local and remote dies is determined. Thus, by obtaining the precise transmission and reception times of the same flow control unit and combining them with a predetermined calibration delay, the data transmission delay of the inter-die interconnect can be directly and accurately measured within the D2D system, improving performance analysis efficiency and facilitating system performance optimization.

[0040] To illustrate the technical solution of this application, specific embodiments are described below.

[0041] Reference Figure 3 This illustration shows a flowchart of a performance monitoring method for a die interconnect system provided in an embodiment of this application. The die interconnect system includes a local die and a remote die. The performance monitoring method can be executed by a performance monitoring device (PMU), which can be located in each die of the die interconnect system. During pre-silicon and post-silicon testing phases, the performance monitoring device can directly acquire the performance data of the die-to-die (D2D) system.

[0042] like Figure 3 As shown, the performance monitoring method for this die interconnect system may include the following steps:

[0043] Step 301: When the local die sends the target flow control unit information to the remote die, the transmission time of the target flow control unit information is obtained through the synchronization counter in the local die, and the reception time of the target flow control unit information is obtained through the synchronization counter in the remote die.

[0044] In D2D, the local die is typically the chip where the main control processor or system management unit resides, serving as the initiator of performance monitoring and the data aggregation point. The remote die, in D2D, is usually the monitored chip, not the one containing the control core. The synchronization counter is a free counter used to record the timing of both the local and remote dies; it supports register configuration to enable and stop counting.

[0045] It should be understood that the structure of the remote die and the local die can be the same. Therefore, in some other embodiments, the remote die can also serve as the initiator of performance monitoring and the data aggregation point. The specific configuration can be combined with the actual application scenario and requirements.

[0046] In this embodiment, the performance monitoring device may include a flow control unit data statistics module, and step 301 can be executed through this flow control unit data statistics module. The flow control unit (Flit) data statistics module can record information about each flow control unit sent and received on the FDI interface. Specifically, the flow control unit information may include a stream ID, a flow control unit tag, and flow control unit time information.

[0047] Specifically, the flow identity identifier indicates the type of the current flow control unit information, originating from the protocol layer or being a non-operational flow control unit (NOP Flit). The flow control unit identifier identifies the current flow control unit information; it can directly use the flow control unit's sequence number, borrow the sequence number built into the protocol itself for preventing packet loss, or be custom-added. The flow control unit time information indicates the time when the current flow control unit information was sent or received.

[0048] Step 302: Determine the data transmission delay between the local die and the remote die based on the pre-determined calibration delay between the local die and the remote die, the transmission time of the target flow control unit information, and the reception time of the target flow control unit information.

[0049] It should be noted that the performance of a die interconnect system includes data transmission latency. Since the data transmission latency of a D2D system ultimately affects the speed of system-level data access and storage, directly and accurately measuring the data transmission latency of the inter-die interconnect within the D2D system can improve the efficiency of performance analysis and is beneficial for system performance optimization.

[0050] The calibration delay refers to the path delay used to transmit control commands (such as configuring, starting, and stopping counters) between two dies, measured through a dedicated calibration process. The calibration delay is a control overhead, not the data transmission time itself; therefore, it needs to be subtracted from the total time difference when determining the data transmission delay between the local and remote dies.

[0051] In this embodiment of the application, the performance monitoring device may further include a performance computing storage device, and step 302 may be executed through the performance computing storage device.

[0052] In one embodiment, if the remote flit time of the target flow control unit information is greater than the local flit time, the data transmission delay between the local and remote dies can be determined by subtracting the transmission time from the reception time of the target flow control unit information, and then subtracting the calibration delay. That is, data transmission delay = Distance(Remote Flit time, Local Flit time) - calibration delay. If remote flit time > local flit time, then Distance(Remote Flit time, Local Flit time) = Remote flit time - local flit time. This is the most intuitive case: the reception time of the target flow control unit information is later than the transmission time, and the synchronization counter has not overflowed and returned to zero. Subtracting these values ​​directly yields the original time difference, which represents the number of counter cycles elapsed from data transmission to reception. Subtracting the calibration delay further gives the data transmission delay between the local and remote dies.

[0053] For example, if the Local Flit time is 10 and the Remote Flit time is 15, then Distance(RemoteFlit time, Local Flit time) = 5.

[0054] In another embodiment, since the synchronization counter is a cyclic, finite-width counter, it is necessary to consider the possibility of the synchronization counter overflowing and returning to zero. Therefore, if the reception time of the target flow control unit information is less than the transmission time of the target flow control unit information, the preset maximum value of the synchronization counter is subtracted from the reception time of the target flow control unit information, added to the transmission time of the target flow control unit information, then incremented by 1, and finally subtracted from the calibration delay to determine the data transmission delay between the local die and the remote die. That is, data transmission delay = Distance(Remote Flittime, Local Flit time) - calibration delay. If the Remote Flit time is less than the Local Flit time, then Distance(Remote Flit time, Local Flit time) = maximum value of the synchronization counter - Remote Flit time + Local Flit time + 1. When the Remote Flit time is less than the Local Flit time, it indicates that the synchronization counter has overflowed and returned to zero during data transmission. The maximum value of the synchronization counter minus the Remote Flit time is the number of remaining cycles from the time of transmission to the time when the synchronization counter reaches its maximum value. The Remote Flit time is the number of cycles from 0 to the time of reception after the synchronization counter overflows and returns to zero. Adding these two cycles together and adding 1 to compensate for the transition cycle from the maximum value to zero gives the complete time difference across the synchronization counter's wraparound point.

[0055] For example, the maximum value of the synchronization counter is 255, the Local Flit time is 254, the Remote Flit time is 2, and the Distance (Remote Flit time, Local Flit time) = 255 - 254 + 2 + 1 = 4. This means that after the target flow control unit sends the information, the counter increments by 1 to 255, then wraps back to 0, and then increments by 2 again until the receiving time, for a total of 4 cycles.

[0056] It should be understood that the maximum value of a synchronous counter is determined by its binary bit width. For example, the theoretical upper limit of the maximum value of an n-bit synchronous counter is 2. n -1.

[0057] Therefore, by distinguishing whether the counter overflows and returns to zero when calculating the delay, and by adopting different time difference calculation strategies, the calculation results of data transmission delay are ensured to be accurate and reliable at any running time.

[0058] In one embodiment, before performing step 302, the calibration delay needs to be determined. The process for determining the calibration delay is described below. The synchronization counters of the local die and the remote die are reset to zero, and a target lock count value (FreezeCounter, FC) is set. The local die's synchronization counter is started via the local die, and a counter start command is sent to the remote die, so that the remote die starts its corresponding synchronization counter upon receiving the counter start command. When the remote die's synchronization counter reaches the target lock count value, it stops counting and sends a reply command to the local die, so that the local die determines its current synchronization counter value upon receiving the reply command. Based on the target lock count value and the local die's current synchronization counter value, the calibration delay between the local die and the remote die is determined. Therefore, by measuring the calibration delay through the complete counter synchronization start, lock, and response mechanism described above, the inherent communication overhead of the control path can be accurately quantified and eliminated, thereby improving the accuracy of the final data transmission delay.

[0059] Specifically, the synchronization counter supports a freeze function, maintaining its value after reaching a preset target freeze value. The control path between the local die and the remote die is configured through the sideband registers. Figure 4 A schematic diagram of a D2D scene provided in an embodiment of this application is shown, such as... Figure 4 As shown, FDI and RDI contain two data types: Mainband and Sideband. Mainband is used to transmit data streams, while sideband is used to transmit control information. Sideband control information mainly includes register configuration and link control negotiation information. Through the sideband interface, not only can the local die's adapter layer and physical layer registers be configured, but the corresponding registers of the remote die can also be accessed.

[0060] In the above Figure 4 Based on this, the latency of the modified configuration path can be calibrated by referring to, for example... Figure 5Schematic diagram of the calibration process shown. The local Die stop counter and the synchronization counter are reset to zero. The local Die sends register configurations to the remote Die to stop the synchronization counter of the remote Die, and the synchronization counter of the remote Die is reset to zero. The local Die sends register configurations to the remote Die to set the target lock count value of the synchronization counter. The local Die starts the synchronization counter and simultaneously sends register configurations to the remote Die to start the synchronization counter of the remote Die (an example of a counter start instruction). When the synchronization counter of the remote Die reaches the target lock count value, it stops counting and simultaneously sends a response to the local Die (Response, an example of a reply instruction). After the local Die receives the reply instruction from the remote Die, it records the current value RC of the synchronization counter. Finally, the calibration delay is obtained by combining the target lock count value FC and the current value RC of the synchronization counter.

[0061] In one embodiment, when the current value of the synchronization counter corresponding to the local die is greater than the target lock count value, the difference between the current value of the synchronization counter corresponding to the local die and the target lock count value is divided by 2 to obtain the calibration delay between the local die and the remote die. That is, calibration delay = Distance(RC, FC) / 2. If RC > FC, Distance(RC, FC) = RC - FC. RC > FC indicates that when the synchronization counter of the remote Die reaches the target lock count value, the response of the local Die is received within the same synchronization counter cycle.

[0062] In another embodiment, when the current value of the synchronization counter corresponding to the local die is less than the target lock count value, the maximum value of the preset synchronization counter is subtracted from the target lock count value, then the current value of the synchronization counter corresponding to the local die is added, and then 1 is added. The obtained value is divided by 2 to obtain the calibration delay between the local die and the remote die. That is, calibration delay = Distance(RC, FC) / 2. If RC < FC, Distance(RC, FC) = maximum value of the synchronization counter - FC + RC + 1. RC < FC indicates that during the response return, the synchronization counter of the local Die wraps around from the maximum value to 0.

[0063] The purpose of the above calibration process is to measure the total time required for a control command to be sent from the local Die, reach the remote Die and make it execute, and then return its response to the local Die. Thus, by also considering the situation of counter overflow and reset in the calculation of the calibration delay and performing corresponding processing, the measurement accuracy of the calibration delay itself is ensured not to be affected by the counter bit width limitation, laying a solid foundation for high-precision delay calculation.

[0064] The performance monitoring method for a die interconnect system disclosed in the above embodiments of this application firstly obtains the transmission time of the target flow control unit information by using a synchronization counter in the local die and the reception time of the target flow control unit information by using a synchronization counter in the remote die when the local die sends target flow control unit information to a remote die. Then, based on a predetermined calibration delay between the local and remote dies, the transmission time of the target flow control unit information, and the reception time of the target flow control unit information, the data transmission delay between the local and remote dies is determined. Therefore, by obtaining the precise transmission and reception times of the same flow control unit and combining them with a predetermined calibration delay, the data transmission delay of the inter-die interconnect can be directly and accurately measured within the D2D system, improving performance analysis efficiency and facilitating system performance optimization.

[0065] In one possible implementation of this application, from the perspective of the entire system, when data originates from a processor or a master device of a NoC and is ultimately transmitted to the other end, the entire path passes through multiple nodes. These nodes operate at different frequencies, and the First-In-First-Out (FIFO) sizes used for data buffering also differ. When the rates or FIFOs of different nodes mismatch, insufficient UCIe bandwidth utilization occurs, and even under full load, the link may experience interruptions. Therefore, the performance of the die interconnect system also includes bandwidth utilization. The performance monitoring method for the die interconnect system may further include: acquiring at least one flow control unit information transmitted or received by the local die within a preset time period; determining the busy count and idle count of the local die within the preset time period based on the transmission or reception times corresponding to the at least one flow control unit information; and determining the bandwidth utilization corresponding to the local die based on the busy count and idle count of the local die within the preset time period, expressed by the formula:

[0066] Bandwidth utilization = Busy Count / (Busy Count + Idle Count);

[0067] Therefore, by directly counting the number of busy and idle cycles at the interface level, rather than relying on software simulation or estimation, the actual bandwidth utilization of the link can be measured in real time and accurately, providing key data for system performance bottleneck analysis.

[0068] Specifically, you can refer to, for example Figure 6The diagram illustrates performance data acquisition. The clock serves as the system's operating reference, with all operations synchronized on the rising or falling edge of the clock. A high FDI Valid signal indicates that data on the FDI Flit signal line is valid and protocol flow control unit information is being transmitted. FDIFlit is the actual data unit transmitted on the physical link. The diagram demonstrates the UCIe link's ability to transmit two protocol data on the same link. The P1 / P2 protocol flow control unit record (Flit Record) is used to record when P1-Flit and P2-Flit occur on the FDI interface, i.e., Flit-1 and Flit-2. The Busy Count and Idle Count reflect link utilization. The Busy Count increments by one per clock cycle whenever the FDI Valid signal is high, and conversely, the Idle Count increments by one per clock cycle when the FDI Valid signal is low.

[0069] It should be noted that the Flit data statistics module records performance data such as busy count and idle count on the FDI and RDI interfaces, which are used for subsequent performance calculations. The storage device obtains performance data to calculate bandwidth utilization.

[0070] In one possible implementation of this application, multi-protocol data stream transmission is performed, with each protocol data stream having sufficient bandwidth for transmission on the link. Insufficient bandwidth can lead to latency degradation in data transmission. Therefore, the performance of the die interconnect system also includes the bandwidth allocation ratio. The performance monitoring method for the die interconnect system may further include: acquiring flow control unit information of multiple protocols sent or received by the local die within a preset time period; determining the flow control unit information count value corresponding to each protocol based on the flow control unit information of multiple protocols; and determining the bandwidth allocation ratio corresponding to the local die based on the flow control unit information count value corresponding to each protocol. Taking the flow control unit information count values ​​of two protocols (P1 Flit RecordCounter and P2 Flit Record Counter) as an example, the bandwidth allocation ratio can be determined by the following formula:

[0071] Bandwidth allocation ratio = P1 Flit Record Counter / P2 Flit Record Counter;

[0072] Therefore, by counting the number of flow control units according to protocol type, the allocation ratio of different protocol data streams in the total bandwidth can be accurately calculated, providing a direct basis for analyzing and optimizing system resource scheduling in multi-protocol mixed transmission scenarios.

[0073] It should be noted that the Flit data statistics module records performance data such as the number of data transfers on the FDI and RDI interfaces. The number of data transfers needs to be differentiated for each protocol to obtain the data transfer volume for different protocols, which is used for subsequent performance calculations and storage device performance data acquisition for bandwidth allocation ratio calculations.

[0074] In the embodiments of this application, see as follows: Figure 7 The diagram illustrates the performance calculation storage module, which stores and performs calculations on statistical performance data. Internally, a FIFO of a certain depth is used for temporary storage. When the FIFO is not empty, the system's Direct Memory Access (DMA) function is used to copy the performance data to memory or other storage media.

[0075] In this embodiment, the performance data of the remote die can be transmitted to the local die via sideband and then copied to the storage medium; alternatively, it can be directly copied to the storage medium at the remote die. Taking busy and idle counts as examples, the busy and idle counts of the remote die can be read from the local die via sideband and stored; or, the busy and idle counts of the remote die can be stored directly on the remote die. Thus, by providing two storage schemes for remote performance data—unified storage via sideband or direct remote storage—flexible solutions are provided for different system architectures and performance requirements.

[0076] The performance monitoring method for die interconnect systems disclosed in the above embodiments of this application can directly record and store bandwidth and latency data within the D2D system. After starting the performance monitoring device, the software can directly read the bandwidth and latency information of the D2D system, significantly improving performance analysis efficiency and providing strong support for system performance optimization. This method can be used efficiently in both pre-silicon functional verification and post-silicon testing stages. Furthermore, by separately statistically analyzing and comparing the bandwidth utilization of FDI and RDI interfaces, it can also be used to verify the rationality of the adapter layer data path design.

[0077] See Figure 8 The diagram shows a structural schematic of a performance monitoring device for a die interconnect system provided in an embodiment of this application. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0078] The performance monitoring device for a die interconnect system may specifically include the following modules:

[0079] The data statistics module 801 is used to obtain the transmission time of the target flow control unit information through the synchronization counter in the local die and the reception time of the target flow control unit information through the synchronization counter in the remote die when the target flow control unit information is sent from the local die to the remote die.

[0080] The performance calculation storage module 802 is used to determine the data transmission delay between the local die and the remote die based on the pre-determined calibration delay between the local die and the remote die, the transmission time of the target flow control unit information, and the reception time of the target flow control unit information.

[0081] The performance monitoring device for a die interconnect system disclosed in the above embodiments of this application first obtains the transmission time of the target flow control unit information through a synchronization counter in the local die and the reception time of the target flow control unit information through a synchronization counter in the remote die when the local die sends target flow control unit information to the remote die. Then, based on a predetermined calibration delay between the local die and the remote die, the transmission time of the target flow control unit information, and the reception time of the target flow control unit information, the data transmission delay between the local die and the remote die is determined. Therefore, by obtaining the precise transmission and reception times of the same flow control unit and combining them with a predetermined calibration delay, the data transmission delay of the inter-die interconnect can be directly and accurately measured within the D2D system, improving performance analysis efficiency and facilitating system performance optimization.

[0082] Furthermore, in one possible implementation of this application embodiment, the performance computing storage module 802 may specifically include the following units:

[0083] The first calculation unit is used to determine the data transmission delay between the local die and the remote die by subtracting the sending time of the target flow control unit information from the receiving time of the target flow control unit information and then subtracting the value obtained by calibration delay when the receiving time of the target flow control unit information is greater than the sending time of the target flow control unit information.

[0084] The second calculation unit is used to determine the data transmission delay between the local die and the remote die by subtracting the reception time of the target flow control unit information from the maximum value of the preset synchronization counter, adding the transmission time of the target flow control unit information, adding 1, and subtracting the value obtained by calibration delay when the reception time of the target flow control unit information is less than the transmission time of the target flow control unit information.

[0085] Therefore, by distinguishing whether the counter overflows and returns to zero when calculating the delay, and by adopting different time difference calculation strategies, the calculation results of data transmission delay are ensured to be accurate and reliable at any running time.

[0086] Furthermore, in another possible implementation of the embodiments of this application, the performance monitoring device for the above-mentioned die interconnect system specifically includes the following modules:

[0087] The first setting module is used to reset the synchronization counters of the local die and the remote die to zero and set the target lock count value.

[0088] The first sending module is used to start the synchronization counter of the local die through the local die and send a counter start command to the remote die, so that the remote die starts the corresponding synchronization counter when it receives the counter start command.

[0089] The second sending module is used to stop counting and send a reply instruction to the local die when the synchronization counter of the remote die reaches the target lock count value, so that the local die can determine the current synchronization counter value of the local die upon receiving the reply instruction.

[0090] The first determining module is used to determine the calibration delay between the local die and the remote die based on the target lock count value and the synchronization counter value corresponding to the local die.

[0091] Therefore, by using the complete counter synchronization start-up, locking, and response mechanism described above to measure calibration delay, the inherent communication overhead of the control path can be accurately quantified and eliminated, thereby improving the accuracy of the final data transmission delay.

[0092] Furthermore, in another possible implementation of this application embodiment, the first determining module may specifically include the following units:

[0093] The third calculation unit is used to divide the difference between the local die's current synchronization counter value and the target lock count value by 2 when the local die's current synchronization counter value is greater than the target lock count value, in order to obtain the calibration delay between the local die and the remote die.

[0094] The fourth calculation unit is used to subtract the target lock count value from the preset maximum value of the synchronization counter when the current synchronization counter value corresponding to the local die is less than the target lock count value, add the current synchronization counter value corresponding to the local die, add 1, and then divide the resulting value by 2 to obtain the calibration delay between the local die and the remote die.

[0095] Therefore, by considering the case of counter overflow and returning to zero in the calculation of calibration delay and handling it accordingly, the measurement accuracy of calibration delay itself is ensured to be unaffected by the limitation of counter bit width, laying a solid foundation for high-precision delay calculation.

[0096] Furthermore, in another possible implementation of the embodiments of this application, the performance of the above-mentioned die interconnect system also includes bandwidth utilization. The data statistics module 801 is specifically used to: obtain at least one flow control unit information sent or received by the local die within a preset time period; and determine the busy count value and idle count value of the local die within the preset time period according to the sending time or receiving time corresponding to the at least one flow control unit information.

[0097] The performance monitoring device for the aforementioned die interconnect system also includes the following modules:

[0098] The second determining module is used to determine the bandwidth utilization rate of the local chip based on the busy count value and idle count value of the local chip within a preset time period.

[0099] Therefore, by directly counting the number of busy and idle cycles at the interface level, rather than relying on software simulation or estimation, the actual bandwidth utilization of the link can be measured in real time and accurately, providing key data for system performance bottleneck analysis.

[0100] Furthermore, in another possible implementation of this application embodiment, the performance calculation storage module 802 is specifically used to: read the busy count value and idle count value of the remote die through the local die via the sideband, and store the busy count value and idle count value of the remote die; or, store the busy count value and idle count value of the remote die through the remote die.

[0101] Therefore, by providing two storage solutions for remote performance data—either unified storage via sideband or direct remote storage—flexible solutions are offered for different system architectures and performance requirements.

[0102] Furthermore, in another possible implementation of the embodiments of this application, the above-mentioned die interconnect system performance also includes bandwidth allocation ratio, and the above-mentioned data statistics module 801 is specifically used to: obtain the flow control unit information of multiple protocols sent or received by the local die within a preset time period; and determine the flow control unit information count value corresponding to each protocol based on the flow control unit information of multiple protocols.

[0103] The performance monitoring device for the aforementioned die interconnect system also includes the following modules:

[0104] The third determining module is used to determine the bandwidth allocation ratio corresponding to the local bare chip based on the flow control unit information count value corresponding to each protocol.

[0105] Therefore, by counting the number of flow control units according to protocol type, the allocation ratio of different protocol data streams in the total bandwidth can be accurately calculated, providing a direct basis for analyzing and optimizing system resource scheduling in multi-protocol mixed transmission scenarios.

[0106] The performance monitoring device for a die interconnect system disclosed in the above embodiments of this application can directly record and store bandwidth and latency data within the D2D system. After activating the performance monitoring device, the software can directly read the bandwidth and latency information of the D2D system, significantly improving performance analysis efficiency and providing strong support for system performance optimization. This method can be used efficiently in both pre-silicon functional verification and post-silicon testing stages. Furthermore, by separately statistically analyzing and comparing the bandwidth utilization of FDI and RDI interfaces, it can also be used to verify the rationality of the adapter layer data path design.

[0107] The performance monitoring device for the die interconnect system provided in this application embodiment can be applied in the foregoing method embodiment. For details, please refer to the description of the above method embodiment, which will not be repeated here.

[0108] Figure 9 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 9 As shown, the electronic device 900 of this embodiment includes: at least one processor 910 ( Figure 9 The diagram shows only one processor, a memory 920, and a computer program 921 stored in the memory 920 and executable on the at least one processor 910. When the processor 910 executes the computer program 921, it implements the steps in the above-described die interconnect system performance monitoring method embodiment.

[0109] The electronic device 900 can be a desktop computer, laptop, handheld computer, cloud server, or other computing device. This electronic device may include, but is not limited to, a processor 910 and a memory 920. Those skilled in the art will understand that... Figure 9 This is merely an example of electronic device 900 and does not constitute a limitation on electronic device 900. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0110] The processor 910 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0111] In some embodiments, the memory 920 may be an internal storage unit of the electronic device 900, such as a hard disk or memory of the electronic device 900. In other embodiments, the memory 920 may be an external storage device of the electronic device 900, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the electronic device 900. Furthermore, the memory 920 may include both internal and external storage units of the electronic device 900. The memory 920 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 920 can also be used to temporarily store data that has been output or will be output.

[0112] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0113] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0114] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0115] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0116] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0117] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0118] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0119] The implementation of all or part of the processes in the methods of the above embodiments can also be accomplished by a computer program product. When the computer program product is run on an electronic device, the electronic device can implement the steps in the various method embodiments described above.

[0120] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A performance monitoring method for a die interconnect system, characterized in that, The die interconnect system includes local dies and remote dies. The performance of the die interconnect system includes data transmission latency. The method includes: When the local die sends target flow control unit information to the remote die, the transmission time of the target flow control unit information is obtained through the synchronization counter in the local die, and the reception time of the target flow control unit information is obtained through the synchronization counter in the remote die. The data transmission delay between the local die and the remote die is determined based on the pre-determined calibration delay between the local die and the remote die, the transmission time of the target flow control unit information, and the reception time of the target flow control unit information. The step of determining the data transmission delay between the local die and the remote die based on a pre-determined calibration delay between the local die and the remote die, the transmission time of the target flow control unit information, and the reception time of the target flow control unit information includes: If the time of receiving the target flow control unit information is greater than the time of sending the target flow control unit information, the time of receiving the target flow control unit information is subtracted from the time of sending the target flow control unit information, and then the value obtained by subtracting the calibration delay is determined as the data transmission delay between the local die and the remote die. If the time of receiving the target flow control unit information is less than the time of sending the target flow control unit information, the maximum value of the preset synchronization counter is subtracted from the time of receiving the target flow control unit information, and then the time of sending the target flow control unit information is added. Then, 1 is added, and then the value obtained by the calibration delay is subtracted to determine the data transmission delay between the local die and the remote die.

2. The method according to claim 1, characterized in that, Before determining the data transmission delay between the local die and the remote die based on the pre-determined calibration delay between the local die and the remote die, the transmission time of the target flow control unit information, and the reception time of the target flow control unit information, the method further includes: Reset the synchronization counters of the local die and the remote die to zero, and set the target lock count value; The local die starts the synchronization counter of the local die and sends a counter start command to the remote die, so that the remote die starts the synchronization counter corresponding to the remote die when it receives the counter start command; When the synchronization counter of the remote die reaches the target lock count value, the counting stops and a reply instruction is sent to the local die, so that the local die can determine the current synchronization counter value of the local die upon receiving the reply instruction; The calibration delay between the local die and the remote die is determined based on the target lock count value and the synchronization counter value corresponding to the local die.

3. The method according to claim 2, characterized in that, The step of determining the calibration delay between the local die and the remote die based on the target lock count value and the synchronization counter value currently corresponding to the local die includes: If the synchronization counter value corresponding to the local die is greater than the target lock count value, divide the difference between the synchronization counter value corresponding to the local die and the target lock count value by 2 to obtain the calibration delay between the local die and the remote die. If the current synchronization counter value corresponding to the local die is less than the target lock count value, the preset maximum value of the synchronization counter is subtracted from the target lock count value, and then the current synchronization counter value corresponding to the local die is added, then 1 is added, and the resulting value is divided by 2 to obtain the calibration delay between the local die and the remote die.

4. The method according to claim 1, characterized in that, The performance of the die interconnect system also includes bandwidth utilization, and the method further includes: Obtain at least one flow control unit information sent or received by the local die within a preset time period; Based on the transmission or reception times corresponding to the at least one flow control unit information, the busy count value and idle count value of the local die within the preset time period are determined, wherein the busy count value is the total number of clock cycles in which the valid signal of the die interconnect interface or the original die interconnect interface of the sensing flow control unit of the local die is at a high level, and the idle count value is the total number of clock cycles in which the valid signal is at a low level. The bandwidth utilization rate of the local chip is determined based on the busy count and idle count of the local chip within the preset time period.

5. The method according to claim 4, characterized in that, The method further includes: The local die reads the busy and idle counts of the remote die via sideband and stores them; or, The remote die stores the busy count and idle count values ​​of the remote die.

6. The method according to claim 1, characterized in that, The performance of the die interconnect system also includes bandwidth allocation ratio, and the method further includes: Obtain flow control unit information of multiple protocols sent or received by the local bare chip within a preset time period; Based on the flow control unit information of the multiple protocols, determine the flow control unit information count value corresponding to each protocol; The bandwidth allocation ratio corresponding to the local die is determined based on the flow control unit information count value corresponding to each protocol.

7. A performance monitoring device for a die interconnect system, characterized in that, The die interconnect system includes local and remote dies. The performance of the die interconnect system includes data transmission latency. The device includes: The data statistics module is used to obtain the transmission time of the target flow control unit information through a synchronization counter in the local die and the reception time of the target flow control unit information through a synchronization counter in the remote die when the local die sends the target flow control unit information to the remote die. The performance calculation and storage module is used to determine the data transmission delay between the local die and the remote die based on the pre-determined calibration delay between the local die and the remote die, the transmission time of the target flow control unit information, and the reception time of the target flow control unit information; The performance computing and storage module includes the following units: The first calculation unit is configured to, when the reception time of the target flow control unit information is greater than the transmission time of the target flow control unit information, subtract the transmission time of the target flow control unit information from the reception time of the target flow control unit information, and then subtract the value obtained by the calibration delay to determine the data transmission delay between the local die and the remote die. The second calculation unit is used to determine the data transmission delay between the local die and the remote die when the reception time of the target flow control unit information is less than the transmission time of the target flow control unit information. This is done by subtracting the reception time of the target flow control unit information from the maximum value of the preset synchronization counter, adding the transmission time of the target flow control unit information, adding 1, and then subtracting the value obtained from the calibration delay.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 6.

9. A computer program product, characterized in that, The computer program product includes a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 6.

Images