Electronic device

Abstract

An electronic device may include a die including at least one circuit configured to receive first information using a first channel of an on-die interface, receive second information using a second channel of the on-die interface, generate one or more transactional units including the first information and the second information, and transmit the transactional units to the die. And transmitting the one or more transactional units using at least one die-to-die system. An electronic device may include a die including at least one circuit configured to receive first information for a first transaction using at least one on-die interface, receive second information for a second transaction using the at least one on-die interface, and transmit the first information to the at least one on-die interface. One or more transactional units including the first information and the second information are generated, and the one or more transactional units are transmitted using at least one die-to-die system.

Description

[0001] This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 601,201, filed on November 20, 2023, and U.S. Patent Application No. 18 / 943,849, filed on November 11, 2024, which are incorporated by reference. Technical Field

[0002] The present disclosure relates generally to communication protocols and, more particularly, to systems, methods, and apparatus for using an on-die protocol with a die-to-die system. Background Art

[0003] An on-die protocol may be used for communication between portions of an integrated circuit fabricated on a die. For example, an on-die protocol may specify how requests, data, responses, etc. may be transmitted between functional blocks on a die (such as processor cores, memory, buffers, controllers, peripheral circuits, etc.).

[0004] The above information disclosed in this Background section is only for enhancement of understanding of the background of the principles of the invention and therefore it may contain information that does not constitute prior art. Summary of the invention

[0005] A device may include a die, including at least one circuit, the at least one circuit configured to: receive first information using a first channel of an on-die interface, receive second information using a second channel of the on-die interface, generate one or more transaction units including the first information and the second information, and send the one or more transaction units using at least one die-to-die system. A first transaction unit of the one or more transaction units may include at least a portion of the first information, and a second transaction unit of the one or more transaction units may include at least a portion of the second information. One of the one or more transaction units may include at least a portion of the first information and at least a portion of the second information. The first information may include information for a first transaction of the on-die interface and information for a second transaction of the on-die interface. The second information may include information for the first transaction of the on-die interface and information for the second transaction of the on-die interface. The at least one die-to-die system may include a path, and the at least one circuit may be configured to: send at least a portion of the first information using the path, and send at least a portion of the second information using the path. The at least a portion of the first information may include control information, and the at least a portion of the second information may include control information. The at least a portion of the first information may include data information, and the at least a portion of the second information may include data information. The at least one die-to-die system may include a first path and a second path, and the at least one circuit may be configured to: send at least a portion of the first information using the first path, and send at least a portion of the second information using the first path. The at least a portion of the first information may include control information, and the at least a portion of the second information may include control information. The at least a portion of the first information may include data information, and the at least a portion of the second information may include data information. One of the one or more transaction units may include error correction information for at least one of the one or more transaction units.

[0006] An apparatus may include a die including at least one circuit configured to: receive first information for a first transaction using at least one on-die interface, receive second information for a second transaction using the at least one on-die interface, generate one or more transaction units including the first information and the second information, and send the one or more transaction units using at least one die-to-die system. One of the one or more transaction units may include at least a portion of the first information and at least a portion of the second information. The at least a portion of the first information may include control information for the first transaction, and the at least a portion of the second information may include control information for the second transaction. The at least a portion of the first information may include data information for the first transaction, and the at least a portion of the second information may include data information for the second transaction. The at least a portion of the die-to-die system may include a path, and the at least a portion of the circuit may be configured to send at least a portion of the first information using the path, and send at least a portion of the second information using the path. The at least a portion of the first information may include control information for the first transaction, and the at least a portion of the second information may include control information for the second transaction. The at least a portion of the first information may include data information for the first transaction, and the at least a portion of the second information may include data information for the second transaction. The at least one die-to-die system may include a first path and a second path, and the at least one circuit may be configured to send at least a portion of the first information using the first path and to send at least a portion of the second information using the first path. The at least a portion of the first information may include control information for the first transaction, and the at least a portion of the second information may include control information for the second transaction. The at least a portion of the first information may include data information for the first transaction, and the at least a portion of the second information may include data information for the second transaction. One of the one or more transaction units may include error correction information for at least one of the one or more transaction units.

[0007] An apparatus may include a die including at least one circuit configured to receive first information using a first on-die interface, receive second information using a second on-die interface, generate one or more transaction units including the first information and the second information, and send the one or more transaction units using at least one die-to-die system. One of the one or more transaction units may include at least a portion of the first information and at least a portion of the second information. The at least a portion of the first information may include control information. The at least a portion of the first information may include data information. A first transaction unit of the one or more transaction units may include at least a portion of the first information, and a second transaction unit of the one or more transaction units may include at least a portion of the second information. The at least a portion of the first information may include control information, and the at least a portion of the second information may include control information. The at least a portion of the first information may include data information, and the at least a portion of the second information may include data information. The at least one die-to-die system may include a path, and the at least one circuit may be configured to send at least a portion of the first information using the path, and send at least a portion of the second information using the path. The at least a portion of the first information may include control information and data information, and the at least a portion of the second information may include control information and data information. The at least one die-to-die system may include a first path and a second path, and the at least one circuit may be configured to send at least a portion of the first information using the first path and to send at least a portion of the second information using the second path. The at least a portion of the first information may include control information, and the at least a portion of the second information may include control information. The at least a portion of the first information may include data information, and the at least a portion of the second information may include data information. One of the one or more transaction units may include error correction information for at least one of the one or more transaction units. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The drawings are not necessarily drawn to scale, and throughout the drawings, for illustrative purposes, elements or portions thereof of similar structure or function may generally be represented by reference indicators ending with and / or containing the same numbers, letters, etc. The drawings are intended only to facilitate the description of the various embodiments described herein. The drawings do not describe every aspect of the teachings disclosed herein and do not limit the scope of the claims. In order to prevent the drawings from becoming obscure, not all components, connections, etc. may be shown, and not all components may have reference numbers. However, the mode of component configuration may be easily clear from the drawings. The drawings, together with the specification, illustrate example embodiments of the present disclosure and, together with the specification, are used to explain the principles of the present disclosure.

[0009] Figure 1A first embodiment of a protocol conversion scheme according to an exemplary embodiment of the present disclosure is shown.

[0010] Figure 2 A second embodiment of the protocol conversion scheme according to an exemplary embodiment of the present disclosure is shown.

[0011] Figure 3 An embodiment of a channel architecture for an on-die protocol according to an example embodiment of the present disclosure is shown.

[0012] Figure 4 An embodiment of a write transaction using an on-die protocol according to an example embodiment of the present disclosure is shown.

[0013] Figure 5 An embodiment of a read transaction using an on-die protocol according to an example embodiment of the present disclosure is shown.

[0014] Figure 6 An embodiment of a die-to-die system according to an example embodiment of the present disclosure is shown.

[0015] Fig. 7A An embodiment of a module configuration for a die-to-die system according to an example embodiment of the present disclosure is shown.

[0016] Figure 7B An embodiment of a multi-module configuration for a die-to-die system according to an example embodiment of the present disclosure is shown.

[0017] Figure 8 An example embodiment of a raw format for a transaction unit according to an example embodiment of the present disclosure is shown.

[0018] Fig. 9 An example embodiment of a latency-oriented flit format for a transaction unit according to an example embodiment of the present disclosure is shown.

[0019] Fig.10 A first embodiment of a transaction unit scheme according to an example embodiment of the present disclosure is shown.

[0020] Fig.11 A second embodiment of the transaction unit scheme according to an example embodiment of the present disclosure is shown.

[0021] Fig.12 A third embodiment of the transaction unit scheme according to an example embodiment of the present disclosure is shown.

[0022] Fig.13 A fourth embodiment of the transaction unit scheme according to an example embodiment of the present disclosure is shown.

[0023] Fig.14A first embodiment of a component configuration for a transaction unit scheme with an on-die interface and a die-to-die path according to an example embodiment of the present disclosure is shown.

[0024] Fig.15 A second embodiment of a component configuration for a transaction unit scheme with multiple on-die interfaces and die-to-die paths according to an example embodiment of the present disclosure is shown.

[0025] Fig.16 A third embodiment of a component configuration for a transaction unit scheme with an on-die interface and multiple die-to-die paths according to an example embodiment of the present disclosure is shown.

[0026] Fig.17 A fourth embodiment of a component configuration for a transaction unit scheme with multiple on-die interfaces and multiple die-to-die paths according to an example embodiment of the present disclosure is shown.

[0027] Fig.18 An example embodiment of a component architecture having one or more modules arranged to communicate combined control information and data information for a protocol conversion scheme is shown according to an example embodiment of the present disclosure.

[0028] Fig.19 An example embodiment of a component architecture having a module for transmitting control information for a protocol conversion scheme and a module for transmitting data information for a protocol conversion scheme according to an example embodiment of the present disclosure is shown.

[0029] Fig. 20 An example embodiment of a transaction unit for transmitting write request information using a raw format according to an example embodiment of the present disclosure is shown.

[0030] Fig.21 An example embodiment of a transaction unit for transmitting write data information using a raw format according to an example embodiment of the present disclosure is shown.

[0031] Fig. 22 An example embodiment of a transaction unit for transmitting write data information using a flit format according to an example embodiment of the present disclosure is shown.

[0032] Fig.23 An example embodiment of a transaction unit for transmitting write response information using a raw format according to an example embodiment of the present disclosure is shown.

[0033] Fig.24 An example embodiment of a transaction unit for transmitting read request information using a raw format according to an example embodiment of the present disclosure is shown.

[0034] Fig.25An example embodiment of a transaction unit for transmitting read data information using a raw format according to an example embodiment of the present disclosure is shown.

[0035] Fig.26 An example embodiment of a transaction unit for transmitting read data information using a flit format according to an example embodiment of the present disclosure is shown.

[0036] Fig. 27 An example embodiment of a transaction unit for transmitting write requests and write data using a raw format and a combined transmission path according to an example embodiment of the present disclosure is shown.

[0037] Fig.28 An example embodiment of a transaction unit for transmitting a write request and write data using a flit format and a combined transmission path according to an example embodiment of the present disclosure is shown.

[0038] Fig.29A and Fig.29B (which may be collectively referred to as FIG. 29 ) illustrates a method for using a Fig. 20 An enlarged view of an example embodiment of a transaction unit transmitting write request information in raw format is shown in FIG.

[0039] Fig. 30A and Fig. 30B (which may be collectively referred to as FIG. 30 ) illustrates a method for using a Fig.21 An enlarged view of an example embodiment of a transaction unit transferring write data information in raw format is shown in FIG.

[0040] Fig.31A and Fig.31B (which may be collectively referred to as FIG. 31 ) illustrates a method for using a Fig. 22 An enlarged view of an example embodiment of a transaction unit transferring write data information in a flit format is shown in FIG.

[0041] Fig.32A and Fig.32B (which may be collectively referred to as FIG. 32 ) illustrates a method for using a Fig.23 An enlarged view of an example embodiment of a transaction unit transmitting write response information in raw format is shown in FIG.

[0042] Fig.33A and Fig.33B (which may be collectively referred to as FIG. 33 ) illustrates a method for using a Fig.24 An enlarged view of an example embodiment of a transaction unit transmitting read request information in raw format is shown in FIG.

[0043] Fig.34A and Fig.34B(which may be collectively referred to as FIG. 34 ) illustrates a method for using a Fig.25 An enlarged view of an example embodiment of a transaction unit transmitting read data information in raw format is shown in FIG.

[0044] Fig.35A and Fig.35B (which may be collectively referred to as FIG. 35 ) illustrates a method for using a Fig.26 An enlarged view of an example embodiment of a transaction unit transmitting read data information in a flit format is shown in FIG.

[0045] Fig.36A , Fig.36B and Fig.36C (which may be collectively referred to as FIG. 36 ) illustrates a method for using a Fig. 27 FIG. 1 is a magnified view of an example embodiment of a transaction unit in which the original format and combined transfer paths transfer write requests and write data.

[0046] Fig.37A , Fig.37B and Fig.37C (which may be collectively referred to as FIG. 37 ) illustrates a method for using a Fig.28 An enlarged view of an example embodiment of a transaction unit that transmits write requests and write data in a flit format and a combined transfer path is shown in FIG. DETAILED DESCRIPTION

[0047] An on-die (OD) protocol may use one or more communication channels to communicate requests, data, responses, etc. between portions of an integrated circuit fabricated on a die (which may also be referred to as a chip). In some example embodiments, the OD protocol may be implemented with an interface having a first channel, a second channel, and / or a third channel, the first channel being used to send a request (e.g., a transaction request (such as a read request or a write request)) from an initiator to a target, the second channel being used to transfer data between the initiator and the target based on the request, and the third channel being used to send a response (e.g., in the case of a write operation) from the target to the initiator to confirm receipt of the data on the second channel.

[0048] In some devices, such as system-in-package (SIP), a die-to-die (D2D) protocol may be used to transfer information between dies within a package. In some embodiments, the D2D protocol may transfer information using one or more transaction units, such as flow control units (flits), raw format transaction units, etc. The transaction unit may have a specified format, which may include, for example, an amount of information, such as a specified number of bytes.

[0049] In some devices, it may be useful to connect an OD interface to a D2D system so that a portion of an integrated circuit on one die can communicate with a portion of an integrated circuit on another die. For example, in some embodiments, a D2D protocol may be used as an intermediary to connect a processor core having a first OD interface on a first die to a memory having a second OD interface on a second die. However, depending on implementation details, such an arrangement may result in relatively inefficient communication. For example, an OD interface may implement a request format, a data format, and / or a response format using signals that may be difficult to transmit using a D2D system (e.g., using clock-by-clock transmission). As a further example, an OD interface may implement one or more formats having a specified number of bytes, which may be different from the number of bytes specified for a transaction unit in a D2D protocol. Therefore, a D2D system may transmit more bytes, flits, etc. than the bytes, flits, etc. that the OD interface to which the D2D system is connected may use or require, thereby increasing overhead and / or reducing the bandwidth of the D2D system.

[0050] In a protocol conversion scheme according to an example embodiment of the present disclosure, information of the OD protocol may be arranged (e.g., packaged) in one or more transaction units of the D2D protocol. For example, information from a first channel (e.g., a request channel) and a second channel (e.g., a data channel) of a transaction of an OD interface may be arranged in one or more transaction units of the D2D system. As another example, information of multiple transactions of the OD protocol may be arranged in one or more transaction units of the D2D system. Depending on implementation details, some of the disclosed techniques may reduce overhead, for example, by reducing unused bytes in a transaction unit and / or by reducing delays caused by sending additional transaction units for additional channels, transactions, etc. Additionally or optionally, some of the disclosed techniques may reduce power consumption, for example, by reducing the amount of control information transmitted with the data information.

[0051] According to an example embodiment of the present disclosure, the protocol conversion scheme may use various hardware configurations. For example, in some embodiments, information of one or more data channels (e.g., write data channels and / or read data channels) and one or more control channels (e.g., channels for commands, requests, addresses, responses, etc.) for the OD interface may be combined and transmitted using a shared hardware module of the D2D system. However, in other embodiments, information of at least a portion of one or more channels for the OD interface may be transmitted using one or more separate hardware modules of the D2D system. For example, in some embodiments, information of one or more data channels for the OD interface may be transmitted using a first module of the D2D system, while information of one or more control channels may be transmitted using a second module of the D2D system.

[0052] According to an example embodiment of the present disclosure, the protocol conversion scheme may use various information formats. In some embodiments, the information format may be based on and / or affected by the underlying hardware configuration. For example, in an embodiment where information for one or more data channels and one or more control channels can be transmitted using a shared hardware module of the D2D system, the transaction unit format may include both control information and data information. One example may include an original format, in which a transaction unit may include control information and data information for one OD interface and / or sequential data information for multiple OD interfaces. Another example may include a delay-oriented format, in which a flit may include control information and / or data information (e.g., in an interleaved configuration) for multiple OD interfaces.

[0053] As another example, in an embodiment where information for one or more data channels and one or more control channels may be transmitted using separate hardware modules of the D2D system, a first transaction unit format may include information for a request channel, a second transaction unit format may include information for a data channel, and a third transaction unit format may include information for a response channel. An example of a transaction unit format for a data channel may include a raw format in which a transaction unit may include data information for one OD interface and / or sequential data information for multiple OD interfaces. Another example of a transaction unit format may include a delay-oriented format in which a flit may include data information for multiple OD interfaces (e.g., in an interleaved configuration).

[0054] Some additional aspects of the present disclosure relate to techniques for detecting and / or correcting information of an OD protocol transmitted using a D2D protocol. For example, some embodiments may use a transaction unit format (e.g., a raw format) in which a transaction layer of the D2D protocol may not implement a retry mechanism. For example, such embodiments may be beneficial in implementations that are particularly sensitive to delays caused by resending data using a retry mechanism (e.g., implementations for high bandwidth memory (HBM)). Some embodiments that avoid a retry mechanism may implement an error correction mechanism (e.g., forward error correction) at the transaction layer to replace or improve the data reliability provided by the retry mechanism.

[0055] Some additional aspects of the present disclosure relate to techniques for indicating valid data on a data channel of an OD interface transmitted using a D2D system. For example, in some embodiments, one or more write strobe signals may be transmitted a reduced number of times (e.g., once) per transaction. In such embodiments, a write strobe pattern may be used to indicate which lanes of a write data channel include valid information for multiple data transmissions. Depending on implementation details, this may reduce the amount of control information transmitted with the corresponding data information.

[0056] The disclosure encompasses many aspects relevant to the protocol conversion scheme. Aspects disclosed herein can have independent utility and can be realized individually, and not each embodiment can utilize each aspect. In addition, aspect can also be realized with various combinations, and some in the various combinations can amplify some benefits of various aspects in a collaborative manner.

[0057] Multiple instances of an element identified with the same base number and different suffixes may be referred to individually and / or collectively by the base number. Figure 2 The one or more initiators 201-0, 201-1, ... shown in FIG. 2 may be individually and / or collectively referred to as an initiator or multiple initiators 201. More generally, within this disclosure, reference to "an" element or "the" element may refer to one or more elements.

[0058] Figure 1 A first embodiment of a protocol conversion scheme according to an exemplary embodiment of the present disclosure is shown. Figure 1 The scheme 100 shown in FIG. 1 may include an initiator 101 having a manager interface 103 for an OD protocol and a target 102 having a slave interface 104 for an OD protocol. The initiator 101, which may be located at a first die 105, may include one or more processors, controllers, memories, and / or any other type of functions that may use the OD interface. The target 102, which may be located at a second die 106, may include one or more processors, controllers, memories, and / or any other type of functions that may use the OD interface.

[0059] In some embodiments, the manager interface (or OD manager interface) 103 and the slave interface (or OD slave interface) 104 may be implemented with one or more OD protocols that may be interoperable if the initiator 101 and the target 102 are located on the same die. However, to facilitate communication between the initiator 101 and the target 102 on the dies 105 and 106, the scheme 100 may include a D2D interconnect scheme 114 that is configured to operate as a bridge between the manager interface 103 and the slave interface 104. Additionally or alternatively, the D2D interconnect scheme 114 may be configured to convert, translate, etc. between one protocol used by the manager interface 103 and another protocol used by the slave interface 104 that may not otherwise be interoperable.

[0060] The D2D interconnection scheme 114 may include a first D2D system 107 located on the first die 105 and a second D2D system 108 located on the second die 106. The first D2D system 107 and the second D2D system 108 may be connected through one or more D2D interfaces 113. Using a set of one or more channels 111, the first D2D system 107 may communicate with the manager interface 103 of the initiator 101 using a slave interface 109 for the OD protocol. Using a set of one or more channels 112, the second D2D system 108 may communicate with the slave interface 104 of the target 102 using a manager interface 110 for the OD protocol.

[0061] A set of channels (e.g., set of channels 111 and / or set of channels 112) may be implemented with one or more signals, which may be arranged in one or more groups of signals corresponding to the one or more channels. Examples of channel types may include control channels (e.g., channels for commands, requests, addresses, responses, etc.), data channels (e.g., write data channels and / or read data channels), etc. Some signals may be exclusive to a particular channel, however, some signals may be shared by two or more channels.

[0062] Examples of OD protocols that may be used for one or more of the OD interfaces 103, 104, 109 and / or 110 may include the Advanced Microcontroller Bus Architecture (AMBA) (including one or more of the AMBA family of protocols such as Advanced Extensible Interface (AXI), Coherent Hub Interface (CHI), AMBA High Performance Bus (AHB), AXI Coherence Extensions (ACE) and / or Advanced Peripheral Bus (APB)), Cache Coherent Interconnect for Accelerators (CCIX), Credit Scalable Streams (CXS), On-Chip Protocol (OCP), Device Transaction Level (DTL), etc.

[0063] Examples of D2D protocols that may be used for one or more D2D systems 107 and / or 108 may include Universal Chiplet Interface Express (UCIe), Bunch of Wires (BOW), Open High Bandwidth Interconnect (OpenHBI), and the like.

[0064] One or both of dies 105 and / or 106 (which may also be referred to as chips) may be implemented as dielets (which may also be referred to as chiplets) and / or any other type of integrated circuit device. Although dies 105 and 106 may be shown as separate components, Figure 1The scheme 100 shown in FIG. 1 may also be used in embodiments where the dies 105 and 106 may be parts that are fabricated on a common die but separated by obstacles, distances, etc. that may be bridged by a D2D interconnect. For example, the D2D interconnect scheme 114 may connect an initiator on a first part of the die with a target on a second part of the die using one or more connections that may pass through one or more vias, a semiconductor bridge (e.g., a silicon bridge), traces on a substrate to which the die is connected, relatively long traces on the die, etc.

[0065] The first die 105 may include conversion logic (e.g., circuitry and / or other functionality) 115 that may convert OD protocol information 117A (e.g., signal operations (such as signal states, timing, modes, etc.)) received from the OD manager interface 103 via the set of one or more channels 111 into a form that may be transmitted using the one or more D2D interfaces 113. For example, in some embodiments, the conversion logic 115 may package the OD protocol information 117A in the form of one or more signal operations (e.g., for one or more transactions, transmissions, etc.) on the set of one or more channels 111 into one or more transaction units that the D2D system 107 may transmit to the D2D system 108 at the second die 106.

[0066] The second die 106 may include conversion logic 116 that may unpack OD protocol information in the form of one or more signal states from one or more transaction units and use the OD protocol information to generate (e.g., reconstruct) one or more signal operations (e.g., of one or more transactions, transfers, etc.) on the set 112 of one or more channels. Thus, the D2D interconnect scheme 114 may transmit the OD protocol information 117A received from the manager interface 103 to the slave interface 104 as reconstructed OD protocol information 117B. The OD protocol information 117A (and / or the reconstructed OD protocol information 117B) may include any information (such as write request information, write data information, read request information, etc.) transmitted from the manager interface to the slave interface.

[0067] In a similar manner, in some embodiments, the conversion logic 116 and / or 115 may also respectively package and unpack the OD protocol information 118A received from the slave interface 104 to enable the D2D interconnection scheme 114 to transmit the OD protocol information 118A as reconstructed OD protocol information 118B to the manager interface 103. The OD protocol information 118A (and / or the reconstructed OD protocol information 118B) may include any information transmitted from the slave interface to the manager interface (such as read data information, write response information, etc.).

[0068] In some embodiments, and depending on implementation details, the protocol conversion scheme 100 may implement a protocol packing and / or unpacking scheme that may enable an initiator 101 on die 105 and a target 102 on die 106 to perform transactions using the OD protocol with little or no impact on the overall performance of the transaction and / or with little or no involvement of adaptation to and / or awareness of the presence of one or more protocol conversion operations (e.g., packing and / or unpacking) and / or the D2D interconnect scheme 114.

[0069] In some embodiments, and depending on implementation details, Figure 1 The protocol conversion scheme 100 shown in the accompanying drawings can implement transactions between an initiator 101 and a target 102 in a manner that can introduce little or no latency in the transaction, cause little or no bandwidth reduction, consume a relatively small amount of power, provide a relatively low bit error rate (BER), and / or provide one or more other benefits as described in more detail herein.

[0070] Although the D2D systems 107 and / or 108 are not limited to any particular implementation details, in some embodiments, either or both of the D2D systems 107 and / or 108 may include a physical layer (also referred to as a phy or PHY layer) and / or a link layer (which may be implemented with an adapter layer (also referred to as an adapter) in some embodiments). In some embodiments, either or both of the conversion logic 115 and / or the OD slave interface 109 may be implemented with a transaction layer that may be separate from the D2D system 107, or as part of a transaction layer that may be separate from the D2D system 107. Additionally or alternatively, either or both of the conversion logic 115 and / or the OD slave interface 109 may be at least partially integrated with the D2D system 107 and / or at least partially implemented with the D2D system 107 (e.g., as part of a link layer). Similarly, in some embodiments, either or both of the OD manager interface 110 and / or the protocol conversion logic 116 may be implemented with a transaction layer that may be separate from, integrated with, or partially integrated with the D2D system 108, or as part of a transaction layer that may be separate from, integrated with, or partially integrated with the D2D system 108.

[0071] In an exemplary embodiment of a write transaction, the initiator 101 may initiate a write operation with the target 102 by using the manager interface 103 to send a write request to the slave interface 109 using the OD protocol, which may be implemented using one or more signals of a write request channel within the set of one or more channels 111. The conversion logic 115 may package the OD protocol information 117A associated with the write request (e.g., one or more states, timing, mode, etc. of one or more signals of the write request channel) into one or more transaction units. The D2D system 107 may transmit the one or more transaction units to the D2D system 108 via the one or more D2D interfaces 113 using the D2D protocol.

[0072] The translation logic 116 at the second die 106 may unpack the OD protocol information 117A from the one or more transaction units to generate a reconstructed version of the OD protocol information 117B associated with the write request. The manager interface 110 may use the reconstructed OD protocol information 117B to forward the write request to the slave interface 104 using an OD protocol (e.g., the same or similar OD protocol used for the OD protocol information 117A), which may be implemented using one or more signals of a write request channel within the set of one or more channels 112.

[0073] Based on sending the write request, the initiator 101 may send write data associated with the write request (e.g., in the form of protocol information 117A) to the slave interface 109 using the OD protocol, which may be implemented using one or more signals of a write data channel within the set of one or more channels 111. For example, by packaging the protocol information 117A associated with the write data into one or more transaction units, the D2D interconnect scheme 114 may forward the write data to the slave interface 104 in a manner similar to that used for the write request, and the one or more transaction units may be unpacked and used to generate reconstructed write data (e.g., in the form of reconstructed protocol information 117B).

[0074] In various embodiments, the D2D interconnection scheme 114 (including the conversion logic 115 and 116) may package the OD protocol information for the write request and the write data at least partially into different transaction units, at least partially into one or more of the same transaction units, or into one or more other transaction unit formats and / or combinations thereof. In various embodiments, the D2D interconnection scheme 114 (including the conversion logic 115 and 116) may transmit the OD protocol information for the write request and the write data at least partially using different hardware paths (e.g., using different hardware modules for the D2D system), at least partially using one or more of the same hardware paths (e.g., the same hardware module for the D2D system), or using one or more other hardware path configurations and / or combinations thereof.

[0075] Based on receiving the write request and / or write data, the target 102 may send a write response (e.g., in the form of protocol information 118A) to the initiator 101 by sending the write response to the manager interface 110 using an OD protocol, which may be implemented using one or more signals of a write response channel within the set of one or more channels 112. The D2D interconnect scheme 114 may forward the write response to the manager interface 103 in a manner similar to that used for the write request and / or write data. For example, the conversion logic 116 may package the protocol information 118A for the write response into one or more transaction units, which the D2D system 108 at the die 106 may send to the D2D system 107 at the die 105. The conversion logic 115 may unpack the protocol information 118A from the one or more transaction units and use the protocol information 118A to generate a reconstructed version 118B of the OD protocol information for the write response, which may be used to send the write response to the manager interface 103 at the initiator 101.

[0076] In various embodiments, the D2D interconnect scheme 114 (including conversion logic 115 and / or 116) may at least partially use a hardware path different from the hardware path used for write requests and / or write data (e.g., using a different hardware module for the D2D system), at least partially use the same hardware path used for at least a portion of the write requests and / or write data, or use one or more other hardware path configurations and / or combinations thereof to transmit OD protocol information for write responses.

[0077] In an exemplary embodiment of a read transaction, the initiator 101 may initiate a read operation with the target 102 by using the manager interface 103 to send a read request (e.g., in the form of protocol information 117A) to the slave interface 109, and the D2D interconnect scheme 114 may forward the read request (e.g., in the form of reconstructed protocol information 117B) to the target 102 in a manner similar to that described above with respect to write transactions (e.g., by packaging OD protocol information into one or more transaction units and / or unpacking OD protocol information from one or more transaction units). However, in some embodiments, the read request may be transmitted using one or more signals of a read request channel within the set of one or more channels 111 and / or a read request channel within the set of one or more channels 112.

[0078] Based on receiving the read request, the target 102 may obtain the requested read data that may be sent to the initiator 101 by sending the read data (e.g., in the form of protocol information 118A) via the slave interface 104 using the OD protocol and one or more signals of the read data channel within the set 112 of one or more channels. The D2D interconnect scheme 114 may forward the read data to the manager interface 103 in a manner similar to that used for the write response. For example, the conversion logic 116 may package the protocol information 118A for the read data into one or more transaction units, which the D2D system 108 at the die 106 may send to the D2D system 107 at the die 105. The conversion logic 115 may unpack the protocol information 118A from the one or more transaction units and use the protocol information 118A to generate a reconstructed version 118B of the OD protocol information for the read data, which may be used to send the read data to the manager interface 103 at the initiator 101.

[0079] In some embodiments, the target 102 may send a read response together with the read data to the initiator 101. In various embodiments, the D2D interconnection scheme 114 (including the conversion logic 115 and / or 116) may package the OD protocol information for the read response at least partially into one or more transaction units for transmitting the read data, at least partially into one or more separate transaction units, and / or into one or more other transaction unit formats and / or combinations thereof. In various embodiments, the D2D interconnection scheme 114 (including the conversion logic 115 and / or 116) may transmit the OD protocol information for the read data and the read response at least partially using one or more of different hardware paths (e.g., using different hardware modules for the D2D system), at least partially using one or more of the same hardware paths (e.g., the same hardware modules for the D2D system), or using one or more other hardware path configurations and / or combinations thereof.

[0080] In some embodiments, some or all of the conversion logic 115 and / or 116 may be referred to and / or characterized as a transaction converter. For example, the conversion logic 115 may convert one or more signal operations associated with an OD protocol transaction into D2D protocol information in a stream of one or more transaction units that may be transmitted from the first die 105 to the second die 106, wherein the conversion logic 116 may convert the D2D protocol information in the one or more transaction units into a reconstructed OD protocol transaction.

[0081] Figure 2 A second embodiment of the protocol conversion scheme according to an exemplary embodiment of the present disclosure is shown. Figure 2 The scheme 200 shown in FIG. 2 may include one or more elements that may be similar to elements shown in other figures, wherein similar elements may be indicated by reference numerals ending with and / or including the same numbers, letters, etc.

[0082] Figure 2 The scheme 200 shown in may include one or more initiators 201-0, 201-1, ... and / or a D2D system 207 on a bare die 205 having one or more OD manager interfaces 203-0, 203-1, ..., which are connected to one or more corresponding OD slave interfaces 209-0, 209-1, ... and / or conversion logic 215 via one or more corresponding sets 211-0, 211-1, ... of one or more channels. The scheme 200 may also include a D2D system 208 on one or more targets 202-0, 202-1, ... and / or a bare die 206 having one or more OD slave interfaces 204-0, 204-1, ..., which are connected to one or more corresponding OD manager interfaces 210-0, 210-1, ... and / or conversion logic 216 via one or more corresponding sets 212-0, 212-1, ... of one or more channels.

[0083] In some embodiments, the structure and / or operation of one or more of the individual OD interfaces 203, 204, 209, and / or 210 and / or the corresponding set of one or more channels 211 and / or 212 may be similar to that described with respect to Figure 1 In some embodiments, Figure 2 The OD protocol information 217-0A to 217-2A, 217-0B to 217-2B, 218-0A to 218-2A, 218-0B to 218-2B shown in Figure 1The corresponding OD protocol information shown in is similarly transmitted. However, in Figure 2 In the embodiment shown in , some interfaces and / or channels (e.g., at the same initiator and / or target or connected to the same initiator and / or target) can be configured to aggregate the bandwidth and / or other attributes of multiple interfaces and / or channels. In some embodiments, multiple interfaces 203, 204, 209 and / or 210 at a common component can be referred to and / or characterized as OD interface ports or OD ports.

[0084] Although OD interfaces 203, 204, 209 and / or 210 and / or corresponding sets of one or more channels 211 and / or 212 may be illustrated as using a D2D system scheme 214 having a single D2D system 207 and / or 208 at the die 205 and / or 206, respectively, in some embodiments, for example, multiple instances of a D2D system may be used to support additional bandwidth that may be implemented using multiple OD interfaces.

[0085] Figure 3 An embodiment of a channel architecture for an OD protocol according to an example embodiment of the present disclosure is shown. Figure 3 The channel architecture 320 shown in FIG. 3 may be used in the embodiments disclosed herein including those related to Figure 1 and / or Figure 2 Any of the protocol conversion schemes shown and / or described herein may be implemented in, or used to implement, the protocol conversion schemes disclosed herein including those related to Figure 1 and / or Figure 2 Any of the protocol conversion schemes shown and / or described.

[0086] The channel architecture 320 may include a manager interface 303 (which may be located, for example, at an initiator) and a slave interface 304 (which may be located, for example, at a target), which may communicate using a write request channel 324, a write data channel 325, a write response channel 326, a read request channel 327 and / or a read data channel 328.

[0087] The write request channel 324 may be implemented with one or more signals that may be used to initiate a write transaction with a write request 331. Examples of signals used to implement the write request channel 324 may include one or more of the following: a write address, one or more signals that may indicate the amount of data to be written (e.g., write size, write length, etc.), burst attributes, a valid signal, a ready signal, cache attributes (e.g., information about how a transaction may progress through the system, how a cache and / or buffer may handle a request, etc.), memory protection attributes, a transaction identifier, one or more user signals (e.g., for implementing extensions to write requests), a quality of service (QoS) signal, a region signal (e.g., an identifier for an address region), one or more signals for error checking and / or correction (e.g., a parity signal), etc. The flow of information on the write request channel 324 may generally be from the manager interface 303 to the slave interface 304 as shown by the arrows, but one or more signals (e.g., a ready signal) may be sent from the slave interface 304 to the manager interface 303.

[0088] The write data channel 325 may be implemented with one or more signals that may be used to transfer the write data 332 from the manager interface 303 to the slave interface 304 as part of a write transaction based on the write request 331. Examples of signals for implementing the write data channel 325 may include one or more write data signals and / or one or more of the following: a valid signal, a ready signal, a last signal (e.g., used to indicate the last transfer), one or more strobe signals (e.g., used to indicate which byte lanes of the write data channel contain valid information), one or more strobe on / off signals, one or more user signals (e.g., used to implement expansion of the write data), etc. The flow of information on the write data channel 325 may generally be from the manager interface 303 to the slave interface 304 as shown by the arrows, but one or more signals (e.g., a ready signal) may be sent from the slave interface 304 to the manager interface 303.

[0089] The write response channel 326 may be implemented with one or more signals that may be used to indicate the result of a write transaction, such as a write response 333. Examples of signals used to implement the write response channel 326 may include one or more of the following: a valid signal, a ready signal, a write response signal (e.g., used to indicate the result of one or more write transfers, transactions, etc.), a completion signal (e.g., used to indicate a completed response), one or more user signals (e.g., used to implement an extension to a write response), an identifier signal (e.g., a transaction identifier for the write channel), etc. The flow of information on the write response channel 326 may generally be from the slave interface 304 to the manager interface 303 as shown by the arrows, but one or more signals (e.g., a ready signal) may be sent from the manager interface 303 to the slave interface 304.

[0090] The read request channel 327 may be implemented with one or more signals that may be used to initiate a read transaction with a read request 334. Examples of signals used to implement the read request channel 327 may include one or more of the following: a read address, one or more signals that may indicate an amount of data to be read (e.g., a read size, a read length, etc.), a burst attribute, a valid signal, a ready signal, a cache attribute (e.g., information about how a transaction may progress through the system, how a cache and / or buffer may handle a request, etc.), a memory protection attribute, a transaction identifier, one or more user signals (e.g., for implementing extensions to a read request), a quality of service (QoS) signal, a region signal (e.g., an identifier for an address region), one or more signals for error checking and / or correction (e.g., a parity signal), etc. The flow of information on the read request channel 327 may generally be from the manager interface 303 to the slave interface 304 as shown by the arrows, but one or more signals (e.g., a ready signal) may be sent from the slave interface 304 to the manager interface 303.

[0091] The read data channel 328 may be implemented with one or more signals that may be used to transfer the read data 335 from the slave interface 304 to the manager interface 303 as part of a read transaction based on the read request 334. Examples of signals for implementing the read data channel 328 may include one or more read data signals and / or one or more of the following: a valid signal, a ready signal, a last signal (e.g., used to indicate the last transfer), a read response signal (e.g., used to indicate whether the device with the slave interface 304 successfully read the requested data, whether the data in a particular transfer and / or transaction is valid, etc.), one or more read blocking and / or read strobe signals, one or more user signals (e.g., used to implement extensions to the read data), etc. The flow of information on the read data channel 328 may generally be from the slave interface 304 to the manager interface 303 as shown by the arrows, but one or more signals (e.g., a ready signal) may be sent from the manager interface 303 to the slave interface 304.

[0092] Figure 4 An embodiment of a write transaction using an on-die protocol according to an example embodiment of the present disclosure is shown. Figure 4 The transaction (e.g., write transaction) 436 shown in FIG. 4 may be implemented in any of the channel architectures disclosed herein, or used to implement any of the channel architectures disclosed herein. One or more signals used by a write request channel, a write data channel, and / or a write response channel may use the nomenclature set forth in, for example, Table 1.

[0093] Transaction 436 may be initiated by a write request on the write request channel using one or more rising edges of clock cycles 1 to 3 of the ACLK signal. Write data may be transmitted on the write data channel using rising edges of clock cycles X to X+n-1. A write response may be transmitted on the write response channel using a rising edge of clock cycle Y.

[0094] For purposes of illustration, write transaction 436 may be described in the context of signals used with the AXI protocol, but the same or similar operations may be implemented with any other OD protocol, such as OCP, DTL, etc.

[0095] Figure 4 The timing shown in the is for general information only and may be shown with time intervals between some operations on different channels. However, in some embodiments, operations on different channels may be performed in an overlapping or parallel manner. For example, in some embodiments, information on one or more of the AWADDR signal, the AWVALID signal, the WDATA signal, and / or the WVALID signal may overlap and / or be transmitted on the same clock edge and / or during the same clock cycle.

[0096] Figure 5An embodiment of a read transaction using an on-die protocol according to an example embodiment of the present disclosure is shown. Figure 5 The transaction (e.g., read transaction) 537 shown in FIG. 5 can be implemented in any of the channel architectures disclosed herein, or used to implement any of the channel architectures disclosed herein. One or more signals used by the read request channel and / or the read data channel can use the nomenclature set forth in Table 1, for example.

[0097] A transaction 537 may be initiated by a read request on the read request channel using the rising edge of clock cycles 1 to 3 of the ACLK signal. Read data may be transferred on the read data channel using the rising edge of clock cycles Z to Z+n-1.

[0098] For purposes of illustration, read transaction 537 may be described in the context of signals used with the AXI protocol, but the same or similar operations may be implemented with any other OD protocol, such as OCP, DTL, etc.

[0099] Figure 5 The timing shown in the example is for general information only and can be shown with the time intervals between some operations on different channels. However, in some embodiments, the operations on different channels can be performed in an overlapping or parallel manner.

[0100] Table 1

[0101]

[0102] Figure 6 An embodiment of a D2D system according to an exemplary embodiment of the present disclosure is shown. The D2D system 607 may be used in the present disclosure including the Figure 1 and / or Figure 2 Any of the protocol conversion schemes shown and / or described herein may be implemented in, or used to implement, the protocol conversion schemes disclosed herein including those related to Figure 1 and / or Figure 2 Any of the protocol conversion schemes shown and / or described. For illustrative purposes, the D2D system 607 and / or other components, configurations, formats, etc. of the D2D system may be described in the context of the UCIe protocol. Figure 6 and / or other figures, but the same or similar logical and / or physical structures, operations, functions, etc. may be implemented with any other D2D protocols (such as BOW, OpenHBI, etc.).

[0103] The D2D system 607 may include a transaction layer 638, an adapter layer 640 (also referred to as an adapter), and / or a physical layer 642. The transaction layer 638 and the adapter layer 640 may interact through an adapter interface 639. In some embodiments, the adapter interface 639 may be referred to and / or characterized as a transmission unit-aware interface (e.g., a flit-aware D2D interface (FDI)). The adapter layer 640 and the physical layer 642 may interact through a physical layer interface 641. In some embodiments, the physical layer interface 641 may be referred to and / or characterized as a raw interface. The physical layer 642 may send and / or receive information through one or more interfaces 643. In some embodiments, and depending on the implementation details, some or all of the transaction layer 638, the adapter layer 640, and / or the physical layer 642 may implement a transport layer. In some embodiments, and depending on the implementation details, some or all of the transaction layer 638, the adapter layer 640, and / or the physical layer 642 may implement a link layer.

[0104] The physical layer 642 may include devices for implementing one or more D2D interfaces 643 between D2D systems (e.g., D2D systems on separate dies). The interface 643 may include a group of one or more paths. Some interfaces 643 may be implemented with one or more modules, each of which may include one or more paths (e.g., 16 paths per module, 64 paths per module, etc.).

[0105] In some embodiments, interface 643 may be characterized as having an N-byte data path, where N may indicate the total number of data paths in interface 643. For example, an interface implemented with four modules each having 16 data paths may have a 64-byte data path, and an interface implemented with two modules each having 64 data paths may have a 128-byte data path. In some embodiments, one or more paths of a module may be characterized as operating at the same data rate and / or width. In some embodiments, paths of multiple modules operating with a common adapter layer 640 may operate at the same data rate and / or width.

[0106] The adapter layer 640 may coordinate one or more operations of the transaction layer 638 and / or the physical layer 642 to transmit information across one or more interfaces 643 implemented by the physical layer 642. According to an example embodiment of the present disclosure, the adapter layer 640 may implement one or more of various functions, operations, features, etc. For example, the adapter layer 640 may implement a cyclic redundancy check (CRC) for detecting errors and / or a retry mechanism for resending data. The adapter layer 640 may be requested, configured, etc., to implement the CRC and / or retry mechanism, for example, by the transaction layer 638. As another example, the adapter layer 640 may negotiate a protocol, mode, transaction unit format (e.g., raw, flit, etc.), etc. with another D2D system (e.g., a remote partner), and communicate the negotiated configuration to the transaction layer 638. As another example, if the adapter layer 640 is configured to support more than one protocol and / or instance of a protocol (e.g., using one or more protocol stacks), the adapter layer 640 may implement arbitration (ARB) and / or multiplexing (MUX) functions.

[0107] The transaction layer 638 may implement one or more protocols, modes, formats, etc. to transmit information across one or more interfaces 643 through the adapter layer 640 and the physical layer 642. Examples of protocols that may be implemented by the transaction layer 638 may include one or more standard protocols (e.g., PCIe, CXL, etc.), one or more stream protocols, etc. In some embodiments, a stream protocol (which may provide one or more common modes for implementing user-defined protocols) may be used to implement a protocol conversion scheme according to an example embodiment of the present disclosure. For example, according to an example embodiment of the present disclosure, the transaction layer 638 may implement a stream transmission protocol in which information from an OD protocol may be packaged into a raw format, a delay-oriented (e.g., delay-optimized) flit format, etc. In some embodiments, when the raw format is used, some or all of the adapter layer 640 may be bypassed. For example, in some implementations, when a raw format transaction unit is used, the adapter layer 640 may transmit information from the transaction layer 638 to the physical layer 642 without modification. Additionally or optionally, when a raw format transaction unit is used, the retry mechanism of the adapter layer 640 may not be used.

[0108] In some embodiments, a first D2D system (e.g., a first instance of D2D system 607) may be implemented on a first die, and a second D2D system (e.g., a second instance of D2D system 607) may be implemented on a second die. The first interface and the second interface may be connected using one or more connections (e.g., electrical connections, optical connections, etc.) to support one or more communication interfaces 643 between the first D2D system and the second D2D system, and the one or more connections may be implemented using one or more contacts, solder connections, conductors, transmission lines, etc. For example, the first D2D system and the second D2D system may be connected via one or more conductors (e.g., conductive traces configured as transmission lines that may have a characteristic impedance) that pass through one or more substrates, interposers, bridges, etc., on one or more substrates, interposers, bridges, etc., and / or along one or more substrates, interposers, bridges, etc.

[0109] Fig. 7A An embodiment of a module configuration for a D2D system according to an exemplary embodiment of the present disclosure is shown. Fig. 7A The module configuration 744A shown in FIG. 744A may be implemented with any one or more interfaces in the D2D system disclosed herein, or used to implement any one or more interfaces in the D2D system disclosed herein.

[0110] The module configuration 744A may include an adapter layer 740A and a physical layer 742A. The physical layer 742A may include a logical physical layer 745A and an electrical layer (e.g., an analog front end (AFE)) 746A. The electrical layer 746A may include transmitters and / or receivers for any number N of lanes (e.g., 16 lanes (x16), 32 lanes (x32), 64 lanes (x64), etc.) that may form the interface 743A. In some embodiments, the interface 743A may be characterized as having an N-byte data path, where N may indicate the total number of data lanes in the interface 743A. Thus, in Fig. 7A In the module configuration 744A shown in FIG. 7 , the width of the N-byte data path may be the same as the number of data paths in the electrical layer 746A. In some embodiments, one or more (e.g., all) of the paths of the module may transmit information in parallel and / or at the same data rate (e.g., using a common clock signal). For example, in some embodiments, each byte of the N-byte data path may be transmitted on a separate data path. In some embodiments, each bit of the byte may be transmitted sequentially on the corresponding data path (e.g., each bit may be transmitted during a unit interval (UI)).

[0111] Figure 7B An embodiment of a multi-module configuration for a D2D system according to an example embodiment of the present disclosure is shown. Figure 7BThe multi-module configuration 744B shown in FIG. 7 may be implemented with any one or more interfaces in the D2D system disclosed herein, or used to implement any one or more interfaces in the D2D system disclosed herein.

[0112] Figure 7B The multi-module configuration 744B shown in FIG. 744B may include Fig. 7A One or more elements similar to one or more elements shown in the drawings may be indicated by reference numerals ending with and / or containing the same numbers, letters, etc. However, in Figure 7B In the multi-module configuration 744B shown in FIG. 1 , the physical layer 742B may include a first instance of a logical physical layer 745B-0 and a second instance of a logical physical layer 745B-1. The physical layer 742B may also include a first instance of a logical physical layer 745B-0 and a second instance of a logical physical layer 745B-1. 0 The first instance of the electrical layer 746B-0 of the data path and the N 1 A second instance of electrical layer 746B-1 for a data path.

[0113] The physical layer 742B may also include a multi-module logical physical layer 747B, which may be used, for example, to coordinate the operation of two instances of the logical physical layers 745B-0 and 745B-1 and / or the operation of two instances of the electrical layers 746B-0 and 746B-1. For example, in some embodiments, the multi-module logical physical layer 747B may enable separate instances of the logical physical layers 745B-0 and 745B-1 and / or the electrical layers 746B-0 and 746B-1 to operate in parallel at the same data transfer rate (e.g., using a common clock signal), etc. Depending on implementation details, this may enable separate instances of the logical physical layers 745B-0 and 745B-1 and / or the electrical layers 746B-0 and 746B-1 to operate together with the adapter layer 740B (e.g., a single instance of the adapter layer 740B).

[0114] In some embodiments, and depending on implementation details, the multi-module configuration may be configured such that the data paths of the different logical physical layers 745B-0 and 745B-1 and / or electrical layers 746B-0 and 746B-1 operate as a single logical and / or physical interface. In some embodiments, the interface 743B may be characterized as having an N-byte data path, where N may indicate the total number of data paths in the interface 743B. Thus, in Figure 7B In the multi-module configuration 744B shown in FIG. 7 , the width of the N-byte data path may be N=N. 0 +N 1, an embodiment having electrical layers with equal numbers of data paths can be twice the width of the number of data paths in each of electrical layers 746B-0 and 746B-1 (e.g., for a 2×16 path module, N=32, for a 2×32 path module, N=64, for a 2×64 path module, N=128, etc.).

[0115] For purposes of illustration, multi-module configuration 744B may be shown as having two modules, each having the same number of pathways, but in other embodiments, any number of modules may be used, each having any number of pathways. In addition, modules may have different numbers of pathways that may be used together to form a logical and / or physical interface. The pathways described herein may be referred to as primary data path pathways, which may be implemented, for example, with dual simplex signals, and the module configurations described herein may implement one or more additional signals (not shown) (such as sideband signals, forwarding clocks, valid signals, etc.).

[0116] Figure 8 An example embodiment of a raw format for a transaction unit according to an example embodiment of the present disclosure is shown. Figure 8 The raw format 848 shown in FIG. 840 can be used to implement any of the protocol conversion schemes disclosed herein, or can be implemented in any of the protocol conversion schemes disclosed herein. For example, the raw format 848 can be used in Figure 6 Information is transmitted between the transaction layer 638, the adapter layer 640 and / or the physical layer 642 of the D2D system 607 shown in FIG.

[0117] exist Figure 8 In the example embodiment shown in , the original format 848 may include 64 bytes numbered 0 to 63 that may be sent as a unit. However, in other embodiments, the original format may include any amount of information (e.g., any number of bytes). The number of transmissions involved in sending (and / or receiving) the 64-byte original format 848 may depend on the width of the data path of the D2D system. For example, in the case of a 64-byte data path (e.g., using an interface with a single x64 module or four x16 modules), the original format 848 may be sent using a single transmission (e.g., each of bytes 0 to 63 may be transmitted on a corresponding byte path during unit intervals 0 to 7). In the case of a 32-byte data path (e.g., using an interface with a single x32 module or two x16 modules), the original format 848 may be sent using two transmissions (e.g., each of bytes 0 to 31 may be sent on a corresponding one of the 32-byte paths using a first transmission during unit intervals 0 to 7, and each of bytes 32 to 63 may be sent on a corresponding one of the 32-byte paths using a second transmission during unit intervals 8 to 15).

[0118] In some embodiments, the raw format 848 may be used to implement a streaming (e.g., user-defined) protocol in which the transaction layer may pass some or all of the transaction units of information (e.g., 64 bytes) to the physical layer. In some embodiments, and depending on implementation details, the transaction layer may bypass one or more operations of the adapter layer. For example, in some embodiments, the transaction layer may pass some or all of the transaction units of information to the physical layer with little or no modification by the adapter layer. Similarly, at the receiving partner's corresponding D2D system, the physical layer may pass some or all of the transaction units of information to the transaction layer without modification by the adapter layer.

[0119] As another example, in some embodiments, when the raw format 848 is used, one or more data reliability features (eg, error checking mechanisms (such as, CRC mechanisms), retry mechanisms, etc.) may be disabled.

[0120] Fig. 9 An example embodiment of a latency-oriented flit format for a transaction unit according to an example embodiment of the present disclosure is shown. Fig. 9 The delay-oriented flit format 949 shown in FIG. 1 may be used to implement any of the protocol conversion schemes disclosed herein, or may be implemented in any of the protocol conversion schemes disclosed herein. For example, the delay-oriented flit format 949 may be used in Figure 6 Information is transmitted between the transaction layer 638, the adapter layer 640 and / or the physical layer 642 of the D2D system 607 shown in FIG.

[0121] For purposes of illustration, the delay-oriented flit format 949 may be implemented as a delay-optimized flit format having 256 bytes divided into four 64-byte portions (e.g., bytes 0 to 63, bytes 64 to 127, bytes 128 to 191, and / or bytes 192 to 255), one or more (e.g., each) of the four 64-byte portions may be transmitted as a unit. However, in other embodiments, any number of portions of any size may be used. One or more (e.g., each) of the portions of the flit format 949 may include portions of user data that may be referred to as chunks. The number of transmissions involved in sending (and / or receiving) the 256-byte flit format 949 may be based on and / or affected by the width of the data path of the D2D system in a manner similar to that described above with respect to the original format 848 (e.g., each of the four 64-byte portions of the delay-oriented flit format 949 may be transmitted using a single transmission on a 64-byte data path).

[0122] In some embodiments, the delay-oriented flit format 949 may be used to implement a streaming (e.g., user-defined) protocol in which a transaction layer may pass some or all of a flit of user information (e.g., 250 bytes of user information organized as four blocks within a 256-byte flit) to an adapter layer, which may add additional information to the flit (e.g., adding some or all of the flit header bytes FHB0 and / or FHB1 to the portion in bytes 0 to 63). Additionally or alternatively, the adapter layer may add data reliability information (e.g., adding CRC code bytes C0B0 and C0B1 to the portion in bytes 64 to 127, and adding CRC codes C1B0 and C1B1 to the portion in bytes 192 to 255), which may be used by the adapter layer at the sending and / or receiving partner (e.g., the D2D system at the sending and receiving ends of the interface) to implement error detection and / or retry mechanisms.

[0123] In some embodiments, the flit header bytes FHB0 and / or FHB1 may include information provided by the transaction layer and / or the adapter layer (such as one or more protocol, mode and / or format identifiers, stack identifiers, acknowledgement (ACK) and / or non-acknowledgement (NACK) information, etc.).

[0124] For purposes of illustration, user information may be organized as 62-byte chunk 0 in bytes 2 to 63, 62-byte chunk 1 in bytes 64 to 125, 64-byte chunk 2 in bytes 128 to 191, and 62-byte chunk 3 in bytes 192 to 253, but any other number and / or combination of chunks of user information may be used. Additionally or alternatively, any other amount and / or location may be used for flit header and / or CRC code information. In some embodiments, some or all of the contents of chunk 0, chunk 1, chunk 2, and / or chunk 3 may be provided by a transaction layer, for example, to implement a protocol conversion scheme according to an example embodiment of the present disclosure.

[0125] In some embodiments, the delay-oriented flit format 949 may enable delay-sensitive information in a portion (e.g., block 0 and / or block 1 of user information) to be transmitted and / or processed before other blocks of the flit format 949 are transmitted. Depending on the implementation details, this may reduce the delay involved in transmitting and / or processing delay-sensitive information. In addition, by implementing a relatively early CRC and / or retry mechanism (e.g., by placing CRC information in bytes 126 and / or 127), the delay-oriented flit format 949 may ensure the reliability level (e.g., BER) of the relatively early arriving portion of the flit. For example, C0B0 and C0B1 may be used to perform error detection on information in the first 128 bytes of the flit format 949 before the last 128 bytes are transmitted.

[0126] Refer again Figure 1 Without one or more techniques according to example embodiments of the present disclosure, it may be difficult to communicate OD protocol information 117 and / or 118 between initiator 101 and target 102 using a D2D interconnect. For example, some or all of protocol information 117 and / or 118 (e.g., for one or more transactions, transmissions, etc.) may be in the form of signal operations (such as signal states, timing, patterns, etc.) that may be difficult and / or inefficient to communicate using a D2D protocol, thereby increasing latency, reducing bandwidth, increasing energy consumption, etc.

[0127] However, one or more techniques according to example embodiments of the present disclosure may enable the OD protocol information 117 and / or 118 to be converted into a form that can be transmitted using the D2D protocol. For example, in some embodiments, the OD protocol information 117A may be packaged in one or more transaction units in the D2D protocol format at the first D2D system 107 on the first die 105 and sent to the second D2D system 108 at the second die 106, and the OD protocol information 117B may be unpacked (e.g., reconstructed) from the one or more transaction units in the second D2D system 108. Depending on implementation details, protocol conversion according to example embodiments of the present disclosure may reduce latency, increase bandwidth, reduce energy consumption, etc.

[0128] Fig.10 A first embodiment of a transaction unit scheme according to an example embodiment of the present disclosure is shown. Fig.10 The transaction unit scheme 1050 shown in FIG. 1050 may be used to implement any of the protocol conversion schemes disclosed herein, or may be implemented with any of the protocol conversion schemes disclosed herein. For example, the transaction unit scheme 1050 may be at least partially implemented with respect to Figure 1 and / or Figure 2 The D2D interconnection schemes 114 and / or 214 shown and described, and / or using Figures 3 to 9 Any of the channel architectures, transactions, D2D systems, transaction unit formats (e.g., raw, flit, etc.), module and / or path configurations, etc. shown and described may be implemented.

[0129] Reference Fig.10 , the transaction unit scheme 1050 may include a first conversion logic 1015 and a first D2D data path 1051 located at a first die (die 0), and a second conversion logic 1016 and a second D2D data path 1052 located at a second die (die 1). The first D2D data path 1051 and the second D2D data path 1052 may be connected via a D2D interface 1013. In some embodiments, the first conversion logic 1015 and / or the second conversion logic 1016 may be, for example, at least partially implemented by a transaction layer (such as, Figure 6 638) shown and described herein) to implement, or for example at least partially to implement, a transaction layer (such as, for example, Figure 6 Transaction layer 638 shown and described).

[0130] The first conversion logic 1015 may, for example, use an OD interface such as Figure 1 1, . . . (which may be individually and / or collectively referred to as 1053)”.

[0131] The D2D data paths 1051 and 1052 and the D2D interface 1013 may transmit one or more transaction units 1053 to the second conversion logic 1016, which may convert the one or more transaction units 1053 into a reconstructed version of the OD protocol information 1017B, for example by unpacking the OD protocol information from the one or more transaction units 1053. The second conversion logic 1016 may, for example, use an OD interface (such as, Figure 1 OD slave interface 104 shown in ) to send the reconstructed version of the OD protocol information 1017B (eg, to the target).

[0132] Any of the one or more transaction units 1053 may include control information (Ctrl) and / or data information (Data). For example, if the OD protocol information 1017A and / or 1018B includes information for a write transaction and a read transaction, the first transaction unit 1053_0 may have a first part and a second part, the first part including control information for the write transaction (e.g., a write address for a write request, a write size, a write length, a write ID, etc.), and the second part including data information for the write transaction (e.g., one or more first bytes of write data, valid, strobe, last, etc.). The second transaction unit 1053_1 may include all data information for the write transaction (e.g., one or more subsequent bytes of write data, valid, strobe, last, etc.). The third transaction unit 1053_2 (which may be indicated by an ellipsis (...) after the second transaction unit 1053_1) may include a first part and a second part, the first part including data information for a write transaction (for example, one or more last bytes of write data for a write transaction, valid, enable, last, etc.), and the second part including control information for a read transaction (for example, a read address, a read size, a read length, a read ID, etc. for a read request).

[0133] The first translation logic 1015 and the second translation logic 1016 may operate in a similar manner but in opposite directions to transfer the OD protocol information 1018A (e.g., from the target) from die 1 to die 0 (e.g., to the initiator). For example, the second translation logic 1016 may generate a stream of one or more transaction units 1054_0, 1054_1, ... (which may be individually referred to and / or collectively referred to as 1054) by packaging the OD protocol information 1018A into one or more transaction units 1054, and the first translation logic 1015 may unpack the one or more transaction units 1054 to generate a reconstructed version of the OD protocol information 1018B.

[0134] Any of the one or more transaction units 1054 may include control information (Ctrl) and / or data information (Data). For example, continuing the example discussed above where the OD protocol information 1017A and / or 1018B may include information for a write transaction and a read transaction, the first transaction unit 1054_0 may have a first part and a second part, the first part including control information for a write transaction (e.g., a write response), and the second part including data information for a read transaction (e.g., one or more first bytes of read data, valid, last, etc.). The second transaction unit 1054_1 may include all data information for a read transaction (e.g., one or more subsequent bytes of read data, valid, last, etc.). The third transaction unit 1054_2 (which may be indicated by an ellipsis (...) after the second transaction unit 1054_1) may include a first part and a second part, the first part including data information for a read transaction (e.g., one or more last bytes of read data, valid, last, etc.), and the second part may include control information (e.g., a write response for a different write transaction), data information (e.g., read data for a different read transaction), etc.

[0135] Thus, in some embodiments, the transaction unit scheme 1050 may convert one or more OD protocol transactions implemented at die 0 using OD protocol information 1017A and / or 1018B into one or more transaction units, which may be transmitted to die 1 using the D2D protocol via interface 1013 and converted back into one or more OD protocol transactions implemented at die 1 using OD protocol information 1017B and / or 1018A.

[0136] In some embodiments, the first conversion logic 1015 may at least partially implement an OD protocol interface (e.g., an OD slave interface for communicating with a corresponding OD manager interface). In some embodiments, the second conversion logic 1016 may at least partially implement an OD protocol interface (e.g., an OD manager interface for communicating with a corresponding OD slave interface).

[0137] In some embodiments, the first conversion logic 1015 and / or the second conversion logic 1016 may be, for example, at least partially implemented by a transaction layer (such as, for example, Figure 6 638) shown and described herein) to implement, or for example at least partially to implement, a transaction layer (such as, for example, Figure 6 Transaction layer 638 shown and described).

[0138] Fig.10 The arrangement of transaction units 1053 and / or 1054 and / or other transaction units shown in other figures may not necessarily indicate the order in which the transaction units may be transmitted.

[0139] Fig.11 A second embodiment of the transaction unit scheme according to an example embodiment of the present disclosure is shown. Fig.11 The transaction unit scheme 1150 shown in FIG. 1 may be used to implement any of the protocol conversion schemes disclosed herein, or may be implemented with any of the protocol conversion schemes disclosed herein. For example, the transaction unit scheme 1150 may be at least partially implemented with respect to Figure 1 and / or Figure 2 The D2D interconnection schemes 114 and / or 214 shown and described, and / or using Figures 3 to 9 Any of the channel architectures, transactions, D2D systems, transaction unit formats (e.g., raw, flit, etc.), module and / or path configurations, etc. shown and described may be implemented.

[0140] Reference Fig.11 , the transaction unit scheme 1150 may include one or more elements that may be similar to one or more elements shown in other figures, wherein similar elements may be indicated by reference numbers ending with and / or containing the same numbers, letters, etc.

[0141] Additionally or alternatively, the transaction unit scheme 1150 may convert OD protocol information from more than one OD interface on at least one of the two dies. For example, the first conversion logic 1115 may be connected to the OD manager interfaces 1103-0, 1103-1, ... to exchange OD protocol information 1117-0A and / or 1118-0B, 1117-1A and / or 1118-1B, ... respectively. Similarly, the second conversion logic 1116 may be connected to the OD slave interfaces 1104-0, 1104-1, ... to exchange OD protocol information 1117-0B and / or 1118-0A, 1117-1B and / or 1118-1A, ... respectively.

[0142] Similar to Fig.10 In the manner of the transaction unit scheme 1050 shown in FIG. 1 , the first conversion logic 1115 and / or the second conversion logic 1116 may package the OD protocol information for one or more transactions into one or more transaction units for the D2D system and / or unpack the OD protocol information for one or more transactions from one or more transaction units for the D2D system.

[0143] Additionally or alternatively, the first conversion logic 1115 and / or the second conversion logic 1116 may package the OD protocol information for one or more OD interfaces into one or more transaction units for the D2D system and / or unpack the OD protocol information for one or more OD interfaces from one or more transaction units for the D2D system. For example, any of the transaction units 1153_0, 1153_1, ... may include control information (Ctrl 0, Ctrl 1, ...) for the OD manager interfaces 1103-0, 1103-1, ..., respectively, and / or data information (Data 0, Data 1, ...) for the OD manager interfaces 1103-0, 1103-1, ..., respectively. Similarly, any of the transaction units 1154_0, 1154_1, ... may include control information (Ctrl 0, Ctrl 1, ...) and / or data information (Data 0, Data 1, ...) for the OD slave interfaces 1104-0, 1104-1, ..., respectively.

[0144] Thus, in some embodiments, and depending on implementation details, the transaction unit scheme 1150 may combine one or more types of information for one or more transactions and / or for one or more OD interfaces in one or more transaction units, which may be transmitted between dies using D2D interconnects in accordance with example embodiments of the present disclosure.

[0145] In some embodiments, the transaction unit scheme 1150 may convert one or more OD protocol transactions implemented at die 0 using OD protocol information 1117-0A, 1118-0B, 1117-1A and / or 1118-1B into one or more transaction units, which may be transmitted to die 1 using the D2D protocol via the D2D interface 1113 and converted back into one or more OD protocol transactions implemented at die 1 using OD protocol information 1117-0B, 1118-0A, 1117-1B and / or 1118-1A.

[0146] In some embodiments, the first conversion logic 1115 may at least partially implement an OD protocol interface (e.g., an OD slave interface for communicating with a corresponding OD manager interface). In some embodiments, the second conversion logic 1116 may at least partially implement an OD protocol interface (e.g., an OD manager interface for communicating with a corresponding OD slave interface).

[0147] In some embodiments, the first conversion logic 1115 and / or the second conversion logic 1116 may be implemented, for example, at least in part, by a transaction layer (such as, for example, Figure 6638) shown and described herein) to implement, or for example at least partially to implement, a transaction layer (such as, for example, Figure 6 Transaction layer 638 shown and described).

[0148] Fig.12 A third embodiment of the transaction unit scheme according to an example embodiment of the present disclosure is shown. Fig.12 The transaction unit scheme 1250 shown in FIG. 1 may be used to implement any of the protocol conversion schemes disclosed herein, or may be implemented with any of the protocol conversion schemes disclosed herein. For example, the transaction unit scheme 1250 may be at least partially implemented with respect to Figure 1 and / or Figure 2 The D2D interconnection scheme 114 and / or 214 shown and described and / or using the Figures 3 to 9 The channel architecture, transactions, D2D system, transaction unit format (e.g., raw, flit, etc.), module and / or path configuration, etc. shown and described may be implemented in any of the above. In some embodiments, the first conversion logic 1215 and / or the second conversion logic 1216 may be implemented at least in part with a transaction layer (e.g., Figure 6 638) shown and described herein) to implement, or at least in part to implement, a transaction layer (such as, Figure 6 Transaction layer 638 shown and described).

[0149] Fig.12 The transaction unit scheme 1250 shown in the figure may include one or more elements that may be similar to one or more elements shown in other figures, wherein similar elements may be indicated by reference numerals ending with and / or containing the same numbers, letters, etc.

[0150] Additionally or alternatively, Fig.12 The transaction unit scheme 1250 shown in FIG. 1 may include more than one D2D interface and / or associated D2D data path at one or more (e.g., each) die. For example, a first D2D data path 1251-0 at die 0 may communicate with a first D2D data path 1252-0 at die 1. A second data path 1251-1 at die 0 may communicate with a second D2D data path 1252-1 at die 1.

[0151] The first conversion logic 1215 and / or the second conversion logic 1216 may convert any type of OD protocol information 1217A, 1217B, 1218A and / or 1218B (e.g., control information, data information, etc.) into D2D protocol information (e.g., by packaging any type of OD protocol information into one or more transaction units for the D2D protocol and / or unpacking any type of OD protocol information from one or more transaction units for the D2D protocol).

[0152] However, in some embodiments, the first conversion logic 1215 and / or the second conversion logic 1216 may use one or more of the D2D data paths and / or associated D2D interfaces at least partially for dedicated purposes. For example, the first conversion logic 1215 may use the D2D data paths 1251-0 and 1252-0 exclusively or primarily for data information (Data). Additionally or alternatively, the first conversion logic 1215 may use the D2D data paths 1251-1 and 1252-1 exclusively or primarily for control information (Ctrl).

[0153] As a first example of at least partially dedicated data path usage, the first conversion logic 1215 may package data information (e.g., write data, valid, strobe, last, etc.) for one or more write transactions in the OD protocol information 1217A and / or 1218B into a first stream of one or more transaction units 1253-0_0, 1253-0_1, ... The first conversion logic 1215 may package control information (e.g., write address, write size, write length, write ID, etc. for write request) for one or more write transactions in the OD protocol information 1217A and / or 1218B into a second stream of one or more transaction units 1253-1_0, 1253-1_1, ... Additionally or alternatively, the first conversion logic 1215 may unpack control information (e.g., write response) for one or more write transactions in the OD protocol information 1217A and / or 1218B from a third stream of one or more transaction units 1254-1_0, 1254-1_1, ...

[0154] A first stream of one or more transaction units 1253-0 may be transferred from Die 0 to Die 1 using the D2D data paths 1251-0 and / or 1252-0 (and / or the D2D interface 1213-0). A second stream of one or more transaction units 1253-1_0, 1253-1_1, ... may be transferred from Die 0 to Die 1 using the D2D data paths 1251-1 and / or 1252-1 (and / or the D2D interface 1213-1). A third stream of one or more transaction units 1254-1_0, 1254-1_1, ... may be transferred from Die 1 to Die 0 using the D2D data paths 1251-1 and / or 1252-1 (and / or the D2D interface 1213_1).

[0155] The second conversion logic 1216 may perform one or more unpacking operations on the first stream of one or more transaction units 1253-0 and / or the second stream of one or more transaction units 1253-1 to generate a reconstructed version 1217B of the OD protocol information 1217A for one or more write transactions. The second conversion logic 1216 may package the OD protocol information 1218A into a third stream of one or more transaction units 1254-1, and the first conversion logic 1215 may unpack the third stream of one or more transaction units 1254-1 to generate a reconstructed version 1218B of the OD protocol information 1218A for one or more write transactions.

[0156] As a second example of at least partially dedicated data path usage, the first conversion logic 1215 may package control information for one or more read transactions (e.g., read address, read size, read length, read ID, etc. for a read request) in the OD protocol information 1217A and / or 1218B into a second stream of one or more transaction units 1253-1_0, 1253-1_1, ... The first conversion logic 1215 may also unpack data information for one or more read transactions (e.g., read data, valid, last, etc.) in the OD protocol information 1217A and / or 1218A from a fourth stream of one or more transaction units 1254-0_0, 1254-0_1, ...

[0157] A second stream of one or more transaction units 1253-1 may be transferred from Die 0 to Die 1 using D2D data paths 1251-1 and / or 1252-1 (and / or D2D interface 1213-1). A fourth stream of one or more transaction units 1254-0 may be transferred from Die 1 to Die 0 using D2D data paths 1251-0 and / or 1252-0 (and / or D2D interface 1213-0).

[0158] The second conversion logic 1216 may perform one or more unpacking operations on the second stream of the one or more transaction units 1253-1 to generate a reconstructed version 1217B of the OD protocol information 1217A for the one or more read transactions. Additionally or alternatively, the second conversion logic 1216 may package the OD protocol information 1218A into a fourth stream of the one or more transaction units 1254-0, and the first conversion logic 1215 may unpack the fourth stream of the one or more transaction units 1254-0 to generate a reconstructed version 1218B of the OD protocol information 1218A for the one or more read transactions.

[0159] In some embodiments, the transaction unit scheme 1250 may convert one or more OD protocol transactions implemented at die 0 using OD protocol information 1217A and / or 1218B into one or more transaction units, which may be transmitted to die 1 using one or more D2D protocols via interfaces 1213-0 and / or 1213-1 and converted back into one or more OD protocol transactions implemented at die 1 using OD protocol information 1217B and / or 1218A.

[0160] In some embodiments, the first conversion logic 1215 may at least partially implement one or more OD protocol interfaces (e.g., one or more OD slave interfaces for communicating with corresponding OD manager interfaces). In some embodiments, the second conversion logic 1216 may at least partially implement one or more OD protocol interfaces (e.g., one or more OD manager interfaces for communicating with one or more corresponding OD slave interfaces).

[0161] In some embodiments, the first conversion logic 1215 and / or the second conversion logic 1216 may be implemented, for example, at least in part, by a transaction layer (such as, for example, Figure 6 638) shown and described herein) to implement, or at least in part to implement, a transaction layer (such as, Figure 6 Transaction layer 638 shown and described).

[0162] Depending on implementation details, at least partially dedicated data path usage as shown and described with respect to transaction unit scheme 1250 may reduce latency, increase bandwidth, reduce energy consumption, etc.

[0163] Fig.13 A fourth embodiment of the transaction unit scheme according to an example embodiment of the present disclosure is shown. Fig.13 The transaction unit scheme 1350 shown in FIG. 1 may be used to implement any of the protocol conversion schemes disclosed herein, or may be implemented with any of the protocol conversion schemes disclosed herein. For example, the transaction unit scheme 1350 may be at least partially implemented with respect to Figure 1 and / or Figure 2 The D2D interconnection schemes 114 and / or 214 shown and described, and / or using Figures 3 to 9 Any of the channel architectures, transactions, D2D systems, transaction unit formats (e.g., raw, flit, etc.), module and / or path configurations, etc. shown and described may be implemented.

[0164] Fig.13 The transaction unit scheme 1350 shown in the figure may include one or more elements that may be similar to one or more elements shown in other figures, wherein similar elements may be indicated by reference numerals ending with and / or containing the same numbers, letters, etc.

[0165] Additionally or alternatively, Fig.13 The transaction unit scheme 1350 shown in FIG. 1 can convert OD protocol information from more than one OD interface on at least one of the two dies. For example, the first conversion logic 1315 can be connected to the OD manager interfaces 1303-0, 1303-1, ... to exchange OD protocol information 1317-0A and / or 1318-0B, 1317-1A and / or 1318-1B, ... respectively. Similarly, the second conversion logic 1316 can be connected to the OD slave interfaces 1304-0, 1304-1, ... to exchange OD protocol information 1317-0B and / or 1318-0A, 1317-1B and / or 1318-1A, ... respectively.

[0166] The first conversion logic 1315 and / or the second conversion logic 1316 may convert any type of OD protocol information 1317-0A, 1317-0B, 1318-0A, 1318-0B, 1317-1A, 1317-1B, 1318-1A and / or 1318-1B (e.g., control information, data information, etc.) into D2D protocol information (e.g., by packing any type of OD protocol information into one or more transaction units for the D2D protocol and / or unpacking any type of OD protocol information from one or more transaction units for the D2D protocol).

[0167] However, in some embodiments, the first conversion logic 1315 and / or the second conversion logic 1316 may use one or more of the D2D data paths and / or associated D2D interfaces at least partially for dedicated purposes. For example, the first conversion logic 1315 and / or the second conversion logic 1316 may use the D2D data paths 1351-0 and / or 1352-0 and / or the D2D interface 1313-0 exclusively or primarily for data information (Data 0, Data 1, ...). Additionally or optionally, the first conversion logic 1315 and / or the second conversion logic 1316 may use the D2D data paths 1351-1 and / or 1352-1 and / or the D2D interface 1313-1 exclusively or primarily for control information (Ctrl 0, Ctrl 1, ...).

[0168] In some implementations of the transaction unit scheme 1350, the first conversion logic 1315 and / or the second conversion logic 1316 may be similar to Fig.12The transaction unit scheme 1250 shown in FIG. 1 packs the data information of the OD protocol for write transactions and / or read transactions into the first stream of one or more transaction units 1353-0 and / or the fourth stream of one or more transaction units 1354-0 and / or unpacks the data information of the OD protocol for write transactions and / or read transactions from the first stream of one or more transaction units 1353-0 and / or the fourth stream of one or more transaction units 1354-0. However, in Fig.13 In the transaction unit scheme 1350 shown in the figure, data information (Data 0, Data 1, ...) for two or more OD manager interfaces 1303-0, 1303-1, ... and / or two or more OD slave interfaces 1304-0, 1304-1, ... may be combined in one or more transaction units 1353-0 and / or 1354-0 that may be transmitted using the first D2D interface 1313-0.

[0169] Additionally or alternatively, the first conversion logic 1315 and / or the second conversion logic 1316 may be similar to Fig.12 The transaction unit scheme 1250 shown in FIG. 1 packs the control information of the OD protocol for write transactions and / or read transactions into the second stream of one or more transaction units 1353-1 and / or the third stream of one or more transaction units 1354-1 and / or unpacks the control information of the OD protocol for write transactions and / or read transactions from the second stream of one or more transaction units 1353-1 and / or the third stream of one or more transaction units 1354-1. However, in Fig.13 In the transaction unit scheme 1350 shown in , control information (Ctrl 0, Ctrl 1, ...) for two or more OD manager interfaces 1303-0, 1303-1, ... and / or two or more OD slave interfaces 1304-0, 1304-1, ... may be combined in one or more transaction units 1353-1 and / or 1354-1 that may be transmitted using the second D2D interface 1313-1.

[0170] Thus, in some embodiments, and depending on implementation details, the transaction unit scheme 1350 may combine one or more types of information for one or more transactions and / or for one or more OD interfaces in one or more transaction units, which may be transmitted between dies using D2D interconnects in accordance with example embodiments of the present disclosure.

[0171] In some embodiments, the first conversion logic 1315 may at least partially implement one or more OD protocol interfaces (e.g., one or more OD slave interfaces for communicating with corresponding OD manager interfaces 1303-0 and / or 1303-1). In some embodiments, the second conversion logic 1316 may at least partially implement one or more OD protocol interfaces (e.g., one or more OD manager interfaces for communicating with one or more corresponding OD slave interfaces 1304-0 and / or 1304-1).

[0172] In some embodiments, the first conversion logic 1315 and / or the second conversion logic 1316 may be implemented, for example, at least in part, by a transaction layer (such as, for example, Figure 6 638) shown and described herein) to implement, or for example at least partially to implement, a transaction layer (such as, for example, Figure 6 Transaction layer 638 shown and described).

[0173] Depending on implementation details, at least partially dedicated data path usage as shown and described with respect to transaction unit scheme 1350 may reduce latency, increase bandwidth, reduce energy consumption, etc.

[0174] Fig.14 A first embodiment of a component configuration of a transaction unit scheme with an on-die interface and a die-to-die path according to an example embodiment of the present disclosure is shown. Fig.14 The component configuration 1450 shown in FIG. 14 can be used to implement any of the protocol conversion schemes disclosed herein, or to be implemented with any of the protocol conversion schemes disclosed herein. For example, the component configuration 1450 can be used at least in part with respect to Figure 1 and / or Figure 2 The D2D interconnection schemes 114 and / or 214 shown and described, and / or using Figures 3 to 9 Any of the channel architectures, transactions, D2D systems, transaction unit formats (e.g., raw, flit, etc.), module and / or path configurations, etc. shown and described may be implemented.

[0175] Fig.14 The component configuration 1450 shown in the figure may include one or more elements that may be similar to one or more elements shown in other figures, wherein similar elements may be indicated by reference numerals ending with and / or including the same numbers, letters, etc. Fig.14 The component configuration 1450 shown in FIG. 1 may be used, for example, to implement Fig.10 The scheme 1050 is shown in FIG.

[0176] Reference Fig.14, the component configuration 1450 may include an OD manager interface 1403 , a packing logic 1455 for a transmit (TX or Tx) operation, an unpacking logic 1456 for a receive (RX or Rx) operation, and / or a D2D transmit and / or receive (TX / RX or Tx / Rx) path 1451 .

[0177] The packing logic 1455 may receive one or more signals on a write request (WReq) channel, one or more signals on a read request (RReq) channel, and / or one or more signals on a write data (WData) channel from the OD manager interface 1403 using the OD protocol. The packing logic 1455 may pack the write request information and / or the write data information into a stream of one or more transaction units 1461. The packing logic 1455 may pack the read request information into a stream of one or more transaction units 1462.

[0178] The D2D transmit and / or receive path 1451 may use the D2D interface 1413 to transmit one or more streams of one or more transaction units 1461 and / or 1462 to another die (e.g., from die 1405 to another die). The D2D transmit and / or receive path 1451 may use the D2D interface 1413 to receive one or more streams of one or more transaction units 1463 and / or 1464 from another die.

[0179] The unpack logic 1456 may unpack the read data (RData) information from the one or more transaction units 1463, and the unpack logic 1456 may convert the one or more transaction units 1463 to the OD protocol and send to the OD manager interface 1403 using one or more signals on the read data channel. In response to the read request information sent in the one or more transaction units 1462, some or all of the read data information may be received.

[0180] The unpack logic 1456 may unpack the write response (WResp) information from the one or more transaction units 1464, and the unpack logic 1456 may convert the one or more transaction units 1464 to the OD protocol and send to the OD manager interface 1403 using one or more signals on the write response channel. In response to the write request information and / or the write data information sent in the one or more transaction units 1461, some or all of the write response information may be received.

[0181] Although the component configuration 1450 is not limited to any particular implementation details, in some embodiments, one or more components may be implemented as, or with, for example, one or more layers of a D2D system. For example, the D2D transmit and / or receive path 1451 may be implemented with a link layer (e.g., an adapter) and / or a PHY layer 1457, the packetization logic 1455 and / or the unpacking logic 1456 may be implemented as a transaction layer 1458, and / or the OD manager interface 1403 may be implemented as part of an application layer 1459.

[0182] Fig.15 A second embodiment of a component configuration of a transaction unit scheme with multiple on-die interfaces and die-to-die paths according to an example embodiment of the present disclosure is shown. Fig.15 The component configuration 1550 shown in FIG. 1 may be used to implement any of the protocol conversion schemes disclosed herein, or may be implemented with any of the protocol conversion schemes disclosed herein. For example, the component configuration 1550 may be at least partially implemented with respect to Figure 1 and / or Figure 2 The D2D interconnection schemes 114 and / or 214 shown and described, and / or using Figures 3 to 9 Any of the channel architectures, transactions, D2D systems, transaction unit formats (e.g., raw, flit, etc.), module and / or path configurations, etc. shown and described may be implemented.

[0183] Fig.15 The component configuration 1550 shown in FIG. 1 may include one or more elements that may be similar to one or more elements shown in other figures, where similar elements may be indicated by reference numerals ending with and / or containing the same numbers, letters, etc. For example, Fig.15 The component configuration 1550 shown in FIG. 1 may be used to implement Fig.11 The scheme 1150 is shown in FIG.

[0184] Reference Fig.15 , the component configuration 1550 may include n OD manager interfaces 1503 - 0 . . . 1503 - n- 1 , a packing logic 1555 , an unpacking logic 1556 , and / or a D2D transmit and / or receive (TX / RX) path 1551 .

[0185] The packing logic 1555 may receive one or more signals on the write request channels WReq 0 ... WReq n-1, one or more signals on the read request channels RReq 0 ... RReq n-1, and / or one or more signals on the write data channels WData 0 ... WData n-1 from the OD manager interface 1503 using one or more OD protocols. The packing logic 1555 may pack the write request information and / or the write data information into a stream of one or more transaction units 1561, some or all of which may include information from more than one of the OD manager interfaces 1503. The packing logic 1555 may pack the read request information into a stream of one or more transaction units 1562, some or all of which may include information from more than one of the OD manager interfaces 1503.

[0186] The D2D transmit and / or receive path 1551 may use the D2D interface 1513 to transmit one or more streams of one or more transaction units 1561 and / or 1562 to another die (e.g., from die 1505 to another die). The D2D transmit and / or receive path 1551 may use the D2D interface 1513 to receive one or more streams of one or more transaction units 1563 and / or 1564 from another die.

[0187] The unpack logic 1556 may unpack read data information from one or more transaction units 1563, and the unpack logic 1556 may convert the one or more transaction units 1563 into one or more OD protocols and send the one or more signals on the read data channels RData 0...RData n-1 to the OD manager interface 1503. The unpack logic 1556 may unpack write response information from one or more transaction units 1564, and the unpack logic 1556 may convert the one or more transaction units 1564 into one or more OD protocols and send the one or more signals on the write response channels WResp 0...WResp n-1 to the OD manager interface 1503.

[0188] Although the component configuration 1550 is not limited to any particular implementation details, in some embodiments, the D2D transmit and / or receive path 1551 may be implemented using a link layer (e.g., an adapter) and / or a PHY layer 1557, the packetization logic 1555 and / or the unpacking logic 1556 may be implemented as a transaction layer 1558, and / or the OD manager interface 1503-0…1503-n-1 may be implemented as part of an application layer 1559.

[0189] Fig.16A third embodiment of a component configuration of a transaction unit scheme with an on-die interface and multiple die-to-die paths according to an example embodiment of the present disclosure is shown. Fig.16 The component configuration 1650 shown in FIG. 1 may be used to implement any of the protocol conversion schemes disclosed herein, or may be implemented with any of the protocol conversion schemes disclosed herein. For example, the component configuration 1650 may be at least partially implemented with respect to Figure 1 and / or Figure 2 The D2D interconnection schemes 114 and / or 214 shown and described, and / or using Figures 3 to 9 Any of the channel architectures, transactions, D2D systems, transaction unit formats (e.g., raw, flit, etc.), module and / or path configurations, etc. shown and described may be implemented.

[0190] Fig.16 The component configuration 1650 shown in FIG. 1 may include one or more elements that may be similar to one or more elements shown in other figures, where similar elements may be indicated by reference numerals ending with and / or containing the same numbers, letters, etc. For example, Fig.16 The component configuration 1650 shown in FIG. 1 may be used to implement Fig.12 The scheme 1250 is shown in FIG.

[0191] Reference Fig.16 , the component configuration 1650 may include the OD manager interface 1603, the packaging logic 1655-0 and / or 1655-1, the unpacking logic 1656-0 and / or 1656-1, the D2D transmission and / or reception path 1651-0, and / or the D2D transmission and / or reception path 1651-1.

[0192] The packing logic 1655-0 may receive write data information from the OD manager interface 1603 using one or more signals of the write data channel using the OD protocol. The packing logic 1655-0 may pack the write data information into a stream of one or more transaction units 1665.

[0193] The D2D transmit and / or receive path 1651-0 may use the D2D interface 1613-0 to send a stream of one or more transaction units 1665 to another die (eg, from die 1605 to another die). The D2D transmit and / or receive path 1651-0 may use the D2D interface 1613-0 to receive a stream of one or more transaction units 1666 from another die.

[0194] The unpack logic 1656 - 0 may unpack read data information from one or more transaction units 1666 , and the unpack logic 1656 - 0 may convert the one or more transaction units 1666 into OD protocol and send to the OD manager interface 1603 using one or more signals on the read data channel.

[0195] The packaging logic 1655-1 may receive write request information and / or read request information from the OD manager interface 1603 using the OD protocol using one or more signals of a write request channel and / or a read request channel, respectively. The packaging logic 1655-1 may package the write request information into a stream of one or more transaction units 1667. The packaging logic 1655-1 may package the read request information into a stream of one or more transaction units 1668.

[0196] D2D transmit and / or receive path 1651-1 may transmit a stream of one or more transaction units 1667 and / or 1668 to another die using D2D interface 1613-1. D2D transmit and / or receive path 1651-1 may receive a stream of one or more transaction units 1669 from another die using D2D interface 1613-1.

[0197] The unpack logic 1656 - 1 may unpack write response information from one or more transaction units 1669 , and the unpack logic 1656 - 1 may convert the one or more transaction units 1669 into OD protocol and send to the OD manager interface 1603 using one or more signals on a write response channel.

[0198] Although the component configuration 1650 is not limited to any particular implementation details, in some embodiments, the D2D transmit and / or receive paths 1651-0 and / or 1651-1 may be implemented with a link layer (e.g., an adapter) and / or a PHY layer 1657, the packetization logic 1655-0 and / or 1655-1 and / or the unpacking logic 1656-0 and / or 1656-1 may be implemented as a transaction layer 1658, and / or the OD manager interface 1603 may be implemented as part of an application layer 1659.

[0199] Fig.17 A fourth embodiment of a component configuration for a transaction unit scheme with multiple on-die interfaces and multiple die-to-die paths according to an example embodiment of the present disclosure is shown. Fig.17 The component configuration 1750 shown in FIG. 1 may be used to implement any of the protocol conversion schemes disclosed herein, or may be implemented with any of the protocol conversion schemes disclosed herein. For example, the component configuration 1750 may be at least partially implemented with respect to Figure 1 and / or Figure 2 The D2D interconnection schemes 114 and / or 214 shown and described, and / or using Figures 3 to 9 Any of the channel architectures, transactions, D2D systems, transaction unit formats (e.g., raw, flit, etc.), module and / or path configurations, etc. shown and described may be implemented.

[0200] Fig.17The component configuration 1750 shown in FIG. 1 may include one or more elements that may be similar to one or more elements shown in other figures, wherein similar elements may be indicated by reference numerals ending with and / or including the same numbers, letters, etc. Fig.17 The component configuration 1750 shown in FIG. 1 may be used, for example, to implement Fig.13 The scheme 1350 is shown in FIG.

[0201] Reference Fig.17 , the component configuration 1750 may include n OD manager interfaces 1703-0...1703-n-1, packaging logic 1755-0 and / or 1755-1, unpacking logic 1756-0 and / or 1756-1, and / or D2D transmission and / or reception paths 1751-0 and / or 1751-1.

[0202] Packing logic 1755 - 0 may receive write data information from OD manager interfaces 1703 - 0 . . . 1703 - n- 1 using one or more OD protocols using one or more signals of write data channels WData 0 . . . WDatan- 1. Packing logic 1755 - 0 may pack write data information into a stream of one or more transaction units 1765 .

[0203] The D2D transmit and / or receive path 1751-0 may use the D2D interface 1713-0 to send a stream of one or more transaction units 1765 to another die (eg, from die 1705 to another die). The D2D transmit and / or receive path 1751-0 may use the D2D interface 1713-0 to receive a stream of one or more transaction units 1766 from another die.

[0204] The unpack logic 1756-0 may unpack read data information from one or more transaction units 1766, and the unpack logic 1756-0 may convert one or more transaction units 1766 into one or more OD protocols and send to the OD manager interface 1703 using one or more signals on the read data channels RData0...RData n-1.

[0205] The packing logic 1755-1 may receive write request information and / or read request information from the OD manager interface 1703-0 ... 1703-n-1 using one or more OD protocols using one or more signals of the write request channel WReq 0 ... WReq n-1 and / or the read request channel RReq 0 ... RReq n-1, respectively. The packing logic 1755-1 may pack the write request information into a stream of one or more transaction units 1767. The packing logic 1755-1 may pack the read request information into a stream of one or more transaction units 1768.

[0206] The D2D transmit and / or receive path 1751-1 may transmit one or more streams of one or more transaction units 1767 and / or 1768 to another die using the D2D interface 1713-1. The D2D transmit and / or receive path 1751-1 may receive one or more streams of transaction units 1769 from another die using the D2D interface 1713-1.

[0207] The unpack logic 1756-1 may unpack write response information from one or more transaction units 1769, and the unpack logic 1756-1 may convert one or more transaction units 1769 into one or more OD protocols and send to the OD manager interface 1703-0...1703-n-1 using one or more signals on the write response channels WResp0...WResp n-1.

[0208] Although the component configuration 1750 is not limited to any particular implementation details, in some embodiments, the D2D transmit and / or receive paths 1751-0 and / or 1751-1 may be implemented using a link layer (e.g., an adapter) and / or a PHY layer 1757, the packetization logic 1755-0 and / or 1755-1 and / or the unpacking logic 1756-0 and / or 1756-1 may be implemented as a transaction layer 1758, and / or the OD manager interfaces 1703-0…1703-n-1 may be implemented as part of an application layer 1759.

[0209] Fig.18 An example embodiment of a component architecture having one or more modules arranged to communicate combined control information and data information for a protocol conversion scheme is shown according to an example embodiment of the present disclosure. Fig.18 The architecture 1850 shown in FIG. 1 may be used to implement any of the protocol conversion schemes disclosed herein, or may be implemented with any of the protocol conversion schemes disclosed herein. For example, the component architecture 1850 may be used at least in part with respect to Figure 1 and / or Figure 2 The D2D interconnection schemes 114 and / or 214 shown and described, and / or using Figures 3 to 9 Any of the channel architectures, transactions, D2D systems, transaction unit formats (e.g., raw, flit, etc.), module and / or path configurations, etc. shown and described may be implemented.

[0210] Fig.18 The component architecture 1850 shown in FIG. 1 may include one or more elements that may be similar to one or more elements shown in other figures, wherein similar elements may be indicated by reference numerals ending with and / or including the same numbers, letters, etc. Fig.18 The component architecture 1850 shown in FIG. 1 may be used, for example, to implement Fig.15 Component configuration 1550 is shown in FIG.

[0211] For illustrative purposes, Fig.18 The embodiments shown in the description may be described in the context of one or more OD interfaces implemented with the AXI protocol and / or a D2D system implemented with UCIe, and may describe specific types of protocol signals, specific numbers of interfaces and / or channels, logic circuits, transmission and / or reception modules, etc., to provide a convenient reference point for describing other aspects of the present disclosure (such as, one or more transaction unit formats described below), possible exemplary implementation details, etc. However, the principles of the present disclosure are not limited to Fig.18 shown in and / or about Fig.18 Describe any details.

[0212] Reference Fig.18 , the component architecture 1850 may include any number of D2D transmit and / or receive modules 1851-0, ..., 1851-3 (in this example, four), any number of instances of packing logic 1855-0, ..., 1855-3 (in this example, four), and / or any number of instances of unpacking logic 1856-0, ..., 1856-3 (in this example, four).

[0213] In some embodiments, one or more of the D2D transmission and / or reception modules 1851 may use, for example, one or more D2D system modules (such as Fig. 7A 7B). The sending and / or receiving module 1851 may be configured to receive a stream of one or more transaction units from a corresponding instance of the packaging logic 1855, which module may use the corresponding D2D interface 1813 to send the stream of one or more transaction units to another bare die. The sending and / or receiving module 1851 may be configured to receive a stream of one or more transaction units from another bare die using the corresponding D2D interface 1813, which module may send the stream of one or more transaction units to a corresponding instance of the unpacking logic 1856.

[0214] exist Fig.18 In the examples shown in , an instance of an OD interface may be referred to as a channel (CH) or an OD interface (I / F) channel. Therefore, a channel may refer to a collection of signals, connections, etc. that may implement an OD interface, and an OD interface may include and / or use one or more channels (which may be referred to and / or characterized as sub-channels) arranged for an OD protocol (such as a control channel (e.g., a channel for commands, requests, addresses, responses, etc.), a data channel (e.g., a write data channel and / or a read data channel), etc.) One or more signals.

[0215] For example, in Fig.18In the embodiment shown in , using the nomenclature of the AXI protocol, CH0 may refer to an OD (eg, AXI) interface having a write request channel AW CH0 , a write data channel W CH0 , a write response channel B CH0 , a read request channel AR CH0 , and / or a read data channel R CH0 .

[0216] Therefore, the packing logic 1855-0 may be configured to receive write request information AW CH0, ..., AW CH3 from OD interface channels CH0, ..., CH3 (indicated as 1870-0, ..., 1870-3), respectively. Additionally or alternatively, the packing logic 1855-0 may be configured to receive read request information AR CH0, ..., AR CH3 from OD interface channels CH0, ..., CH3, respectively. Additionally or alternatively, the packing logic 1855-0 may be configured to receive write data information W CH0, ..., W CH3 using OD interface channels CH0, ..., CH3, respectively.

[0217] Packing logic 1855-0 may be configured to use any format (e.g., Fig.25 and / or Fig.28 One or more of the formats shown and / or described) packages write request information, read request information and / or write data information into a stream of one or more transaction units to generate a stream of one or more transaction units.

[0218] The unpacking logic 1856-0 may be configured to receive a stream of one or more transaction units from the sending and / or receiving module 1851-0, the unpacking logic 1856-0 may unpack the stream of one or more transaction units to generate read data information RCH0, ..., RCH3, and the unpacking logic 1856-0 may send the read data information RCH0, ..., RCH3 using OD interface channels CH0, ..., CH3, respectively. Additionally or alternatively, the unpacking logic 1856-0 may be configured to unpack write response information BCH0, ..., BCH3 from the stream of one or more transaction units, and the unpacking logic 1856-0 may send the write response information BCH0, ..., BCH3 using OD interface channels CH0, ..., CH3 (indicated as 1870-0, ..., 1870-3, respectively).

[0219] Therefore, in some embodiments, the sending and / or receiving module 1851-0 can be configured to send and / or receive a combination of control information (e.g., write request and / or read request, write response, etc.) and data information (e.g., write data, read data, etc.).

[0220] In some embodiments, the packing logic 1855-1, ..., 1855-3, the unpacking logic 1856-0, ..., 1856-3 and / or the D2D transmission and / or reception module 1851-1, ..., 1851-3 can be configured in a similar arrangement to pack and / or unpack and send and / or receive information for OD interface channels CH4, ..., CH15 (indicated as 1870-4, ..., 1870-15) in a manner similar to that described above for OD interface channels CH0, ..., CH3.

[0221] In some embodiments, the OD interface connection 1871 may include one or more connections, switches, etc. to connect one or more signals between the OD interface channel 1870, the packing logic 1855 and / or the unpacking logic 1856.

[0222] In some embodiments, and depending on implementation details, a collection of one or more OD interface channels 1870 (e.g., CH0, ..., CH15) may be referred to and / or characterized as an N-channel OD interface port, where N may indicate the number of OD interface channels (in this example, sixteen). In some embodiments, one or more of the D2D transmit and / or receive modules 1851 may be implemented at least in part with a D2D link layer (e.g., adapter) and / or a D2D Phy layer 1857. In some embodiments, one or more of the packing logic 1855 and / or the unpacking logic 1856 may be implemented at least in part with a transaction layer 1858.

[0223] Fig.19 An example embodiment of a component architecture having a module for transmitting control information for a protocol conversion scheme and a module for transmitting data information for a protocol conversion scheme according to an example embodiment of the present disclosure is shown. Fig.19 The component architecture 1950 shown in FIG. 1 may be used to implement any of the protocol conversion schemes disclosed herein, or may be implemented with any of the protocol conversion schemes disclosed herein. For example, the component architecture 1950 may be used at least in part with respect to Figure 1 and / or Figure 2 The D2D interconnection schemes 114 and / or 214 shown and described, and / or using Figures 3 to 9 Any of the channel architectures, transactions, D2D systems, transaction unit formats (e.g., raw, flit, etc.), module and / or path configurations, etc. shown and described may be implemented.

[0224] Fig.19 The component architecture 1950 shown in FIG. 1 may include one or more elements that may be similar to one or more elements shown in other figures, wherein similar elements may be indicated by reference numerals ending with and / or including the same numbers, letters, etc. Fig.19The component architecture 1950 shown in FIG. 1 may be used, for example, to implement Fig.17 The component configuration 1750 shown in Fig.17 In the component configuration 1750 shown in FIG. 1 , separate modules may be used to communicate control information and data information.

[0225] like Fig.18 The embodiments shown in the drawings are for illustration purposes only. Fig.19 The embodiments shown in the embodiment may be described in the context of one or more OD interfaces implemented with the AXI protocol and / or a D2D system implemented with UCIe, and may describe specific types of protocol signals, specific numbers of interfaces and / or channels, logic circuits, transmission and / or reception modules, etc. However, the principles of the present disclosure are not limited to Fig.19 shown in and / or about Fig.19 Describe any details.

[0226] Reference Fig.19 , the component architecture 1950 may include a first set of one or more modules and / or packaging logic and / or unpacking logic that may be substantially dedicated to transmitting data information and a second set of one or more modules and / or packaging logic and / or unpacking logic that may be substantially dedicated to transmitting control information. In some embodiments, one or more of the D2D transmit and / or receive modules 1951 may be implemented at least in part with a D2D link layer (e.g., adapter) and / or a D2D Phy layer 1957. In some embodiments, one or more of the packaging logic 1955 and / or unpacking logic 1956 may be implemented at least in part with a transaction layer 1958.

[0227] exist Fig.19 In the example embodiment shown in , any number of D2D transmission and / or reception modules (e.g., dedicated modules) 1951-0, ..., 1951-3 (in this example, four) can be used to transmit data information, and any number of instances of packaging logic 1955-0, ..., 1955-3 (in this example, four) and / or any number of instances of unpacking logic 1956-0, ..., 1956-3 (in this example, four) can be configured to package, unpack and / or transmit data information.

[0228] For example, the packing logic 1955-0 may be configured to pack the write data information W CH0, ..., W CH3 for OD interface channels CH0, ..., CH3 respectively into a stream of one or more transaction units, and the stream of one or more transaction units may be sent to another bare die by the D2D transmission and / or reception module 1951-0 through the D2D interface 1913-0. The D2D transmission and / or reception module 1951-0 may receive the stream of one or more transaction units through the D2D interface 1913-0, and the unpacking logic 1956-0 may unpack the stream of one or more transaction units to generate read data information R CH0, ..., R CH3 for OD interface channels CH0, ..., CH3 (indicated as 1970-0, ..., 1970-3), respectively.

[0229] Packing logic 1955-0 and / or unpacking logic 1956-0 may implement any transaction unit format (e.g., Fig.21 , Fig.24 , Fig.26 and / or Fig. 27 One or more of any transaction unit formats shown and / or described).

[0230] exist Fig.19 In the example embodiment shown in , any number of D2D transmit and / or receive modules 1951-4 (in this example, one) may be used to transmit control information, and any number of instances of packetization logic 1955-4 (in this example, one) and / or any number of instances of unpacking logic 1956-4 (in this example, one) may be configured to packetize, unpack and / or transmit control information.

[0231] For example, the packing logic 1955-4 may be configured to pack write request information AW CH0, ..., AW CH15 and / or read request information AR CH0, ..., AR CH15 for OD interface channels CH0, ..., CH15 into a stream of one or more transaction units, which may be sent to another die by the D2D sending and / or receiving module 1951-4 through the D2D interface 1913-4. The D2D sending and / or receiving module 1951-4 may receive the stream of one or more transaction units through the D2D interface 1913-4, and the unpacking logic 1956-4 may unpack the stream of one or more transaction units to generate write response information B CH0, ..., BCH15 for OD interface channels CH0, ..., CH15 (indicated as 1970-0, ..., 1970-15), respectively.

[0232] Packing logic 1955-1 and / or unpacking logic 1956-1 may implement any transaction unit format (e.g., Fig. 20 and / or Fig. 22One or more of any transaction unit formats shown and / or described).

[0233] In some embodiments, and depending on implementation details, using substantially separate dedicated modules for data and control may increase bandwidth and / or throughput, and / or reduce overhead, latency, and / or energy consumption, etc. For example, depending on implementation details, moving control information (e.g., write requests, read requests, write responses, etc.) out of the data path may enable the data path to operate at or near full data transfer speeds without interruptions for control information that may be offloaded to a module that may handle the control information.

[0234] Figures 20 to 28 It is shown that you can use Fig.18 and / or Fig.19 Some example embodiments of transaction unit formats implemented by one or more of the component architectures shown in the present disclosure may provide a convenient context for illustrating aspects of the present disclosure. For purposes of illustration, Figures 20 to 28 The embodiments shown in the may be described in the context of an AXI protocol and / or a D2D system implemented with UCIe, and the AXI nomenclature may be used for various types of information. However, other OD protocols and / or interfaces and / or D2D protocols and / or interfaces may be used, and Fig.18 and / or Fig.19 The component architecture shown in or Figures 20 to 28 The transaction unit formats shown in are not limited to any of the example details disclosed herein.

[0235] Fig. 20 An example embodiment of a transaction unit for transmitting write request information using a raw format according to an example embodiment of the present disclosure is shown. Fig. 20 References to ref. 29 can also be found. For example, Fig. 20 The raw format transaction unit 2080 shown in FIG. 2080 may be used with a component architecture such as that shown in FIG. Fig.12 , Fig.13 , Fig.16 , Fig.17 and / or Fig.19 The present invention may be used in conjunction with one of the component architectures shown and / or described herein, in which control information may be transmitted using a first D2D path, module, etc. and data information may be transmitted using a second D2D path, module, etc.

[0236] For illustrative purposes, Fig. 20 The raw format transaction unit 2080 shown in FIG. 20 can be described in the context of a system in which control information for sixteen OD interface channels CH0, ..., CH15 can be used as shown in FIG. Fig.19The packetization logic (such as the packetization logic 1955-4) and / or the associated D2D transmission and / or reception module 1951-4 are used to packetize and / or transmit. However, Fig. 20 The raw format transaction unit 2080 shown in is not limited to the number and / or type of information, signals, bits, bytes, channels, etc. disclosed herein.

[0237] The raw format transaction unit 2080 may include 256 bytes, of which 16 bytes may be used to transmit control information for 16 corresponding OD interface channels CH0, ..., CH15. For ease of reference to any of the 256 bytes, the raw format transaction unit 2080 (and / or some other transaction units shown in other figures) is shown as a table of 16 bytes with 16 rows, in which the byte number of the first byte in each row is indicated in the left column, and the byte number of any other bytes in the row can be obtained by adding the number in the top row of the table to the number of the first byte in each row. Thus, for example, byte 10 (AWLEN for CH0) in the 256-byte format can be determined by adding +10 from the top row to byte 0 in the left column. As an additional example, the AWADDR for CH0 may be located at bytes 4 to 9, and the AWADDR for CH1 may be located at bytes 20 (byte 16+4) to 25 (byte 16+9).

[0238] The first two bytes in each row of the raw format transaction unit 2080 may include a format header (FH), an example of which is shown as format header 2080A. For ease of reference to any of the 16 bits in the two bytes of format header 2080A, format header 2080A is shown as a table with two rows of one byte (8 bits) each, in which the number of each bit in the byte is indicated in the top row of the table. Thus, format header 2080A may include a first byte FH B0 having bits 0 to 7 and a second byte FH B1 having bits 0 to 7. For example, the write transaction size AWSIZE may be located at bits 3 to 5 of byte FH B1. Format headers shown in other figures for other embodiments of transaction units may be arranged in a similar format.

[0239] Each row of the original format transaction unit 2080 may include write request information for write transactions of the corresponding OD interface channels CH0, ..., CH15. Within each row, the first two bytes may include two header bytes with the format of the header 2080A. For example, the first two bytes (bytes 0 and 1) in the row indicated as byte 0 may include format header bytes FH B0 and FH B1 for CH0 (indicated as FH B0 CH0 and FH B1 CH0, respectively). As another example, the first two bytes (bytes 240 and 241) in the row indicated as byte 240 may include format header bytes FH B0 and FH B1 for CH15 (indicated as FH B0CH15 and FH B1 CH15, respectively). Therefore, the 16 bits for a specific channel CH0, ..., CH15 surrounded by a thick solid line in the format header 2080A may be included in the first two bytes surrounded by a thick solid line in each row of the corresponding channels CH0, ..., CH15 for the original format transaction unit 2080.

[0240] In some embodiments, the information shown in the raw format transaction unit 2080 and / or the format header 2080A may be implemented using the nomenclature set forth in Table 1. Additionally or alternatively, some of the information in the raw format transaction unit 2080 and / or the format header 2080A may be implemented using the nomenclature in Table 2.

[0241] Table 2

[0242] In some embodiments, use of some or all of the information indicated in the raw format transaction unit 2080 and / or the format header 2080A may enable the packing logic 1955 to capture write request information on the write request channel (such as, Figure 4 1950). The packing logic 1955 may pack the captured write request information into raw format transaction units 2080 and / or format headers 2080A that may be transmitted to another die, where the unpacking logic may unpack the raw format transaction units 2080 and / or format headers 2080A to generate a reconstructed version of the write request information on the write request channel as part of the write transaction.

[0243] Although the 256 bytes of the raw format transaction unit 2080 may be shown as byte 0 through byte 255, the information in the raw format transaction unit 2080 may be transmitted in any manner, such as by transmitting the entire 256-byte format in one transmission, or using four 64-bit raw format transmission units, such as by transmitting the entire 256-byte format in one transmission. Figure 81 and / or 2 may be transmitted using a 64-bit raw format transmission unit (e.g., a 64-bit raw format UCIe transmission) as shown and / or described. For example, bytes 0 to 63 may be transmitted using a first 64-bit raw format transmission, bytes 64 to 127 may be transmitted using a second 64-bit raw format transmission, bytes 128 to 191 may be transmitted using a third 64-bit raw format transmission, and / or bytes 192 to 255 may be transmitted using a fourth 64-bit raw format transmission.

[0244] In some embodiments, and depending on implementation details, raw format transaction units (such as Fig. 20 The raw format transaction unit 2080 shown in FIG. 200 may reduce overhead, latency, and / or energy consumption, and / or increase bandwidth and / or throughput, etc., particularly if a component architecture (such as, Fig.19 ) (eg, using dedicated TX / RX modules) to transmit raw format transaction unit 2080.

[0245] Fig.21 An example embodiment of a transaction unit for transmitting write data information using a raw format according to an example embodiment of the present disclosure is shown. Fig.21 References to 30 can also be found. As an example, Fig.21 The raw format transaction unit 2181 shown in FIG. 21 can be used with a component architecture (such as, for example, referring to Fig.12 , Fig.13 , Fig.16 , Fig.17 and / or Fig.19 The invention may be used in conjunction with one of the component architectures shown and / or described herein, in which control information may be transmitted using a first D2D path, module, etc. and data information may be transmitted using a second D2D path, module, etc.

[0246] For illustrative purposes, Fig.21 The raw format transaction unit 2181 shown in FIG. 21 can be described in the context of a system in which write data information for four OD interface channels CH0, ..., CH3 can be written using the following example: Fig.19 In some embodiments, one or more (e.g., three) additional instances of the raw format transaction unit 2181 may be used to package and / or transmit write data information for twelve additional OD interface channels CH4, ..., CH15, which may be packaged and / or transmitted using the packaging logic (e.g., packaging logic 1955-0) and / or associated D2D transmission and / or reception module 1951-0 shown in FIG. Fig.19 , 1955-3 and / or associated D2D transmission and / or reception modules 1951-1, ..., 1951-3) are used for packaging and / or transmission. However, Fig.21 The raw format transaction unit 2181 shown in is not limited to use with the quantities and / or types of information, signals, bits, bytes, channels, components, etc. disclosed herein.

[0247] The original format transaction unit 2181 may include 256 bytes, of which the first portion including the first 64 bytes may be used to transmit write data for OD interface channel CH0 as indicated by the suffix CH0 attached to the format header. The second portion including the second 64 bytes indicated as bytes 64 to 127 may be used to transmit write data for OD interface channel CH1 as indicated by the suffix CH1 attached to the format header and write data in the second four lines of information. The third portion including the third 64 bytes indicated as bytes 128 to 191 may be used to transmit write data for OD interface channel CH2 as indicated by the suffix CH2 attached to the format header and write data in the third four lines of information. The fourth portion including the last 64 bytes indicated as bytes 192 to 255 may be used to transmit write data for OD interface channel CH3 as indicated by the suffix CH3 attached to the format header and write data in the last four lines of information.

[0248] Each 64-byte portion of the raw format transaction unit 2181 may be used to transmit write data for one or more write transactions, and the write data for each transaction may be accompanied by a corresponding format header, an example of which is shown in FIG. Fig.21 181A. The format header 2181A may include, for example, one or more fields identified by the nomenclature set forth in Table 1 and / or Table 2. For example, bytes 0 to 4 indicated as format header 2181A-0 (enclosed by a thick solid line) may include bytes 0 to 4 from a corresponding write data channel signal (such as, Figure 4 The write data channel signals shown in FIG. 4 capture five bytes of write data channel information (such as WVALID, WLAST, WSTRB, etc.), which can be used to transmit write data WDATA for the first write transaction on the OD interface channel CH0.

[0249] The first write transaction may be, for example, comprised of Fig. 20 The write request information in the first 16 bytes (eg, bytes 0 to 15) of the original format transaction unit 2080 shown in FIG. 2 may provide information about the amount of write data included in the first write transaction. For example, Fig. 20One or more of the fields AWSIZE, AWLEN, AWBURST, etc. in the write request information in the raw format transaction unit 2080 shown in FIG. 2 may be used to determine that the first write transaction on CH0 may include 32 bytes of write data as an example. Therefore, bytes 5 to 37 of the raw format transaction unit 2181 may include 32 bytes of write data for the first write transaction (indicated as D0 CH0 to D31 CH0).

[0250] Because the write data for the first write transaction on CH0 (including the format header 2181A) may use less than the 64 bytes allocated for write data for CH0 (excluding two bytes for ECC information discussed below), the packing logic 1955-0 may pack the write data for at least a portion of the second write transaction into raw format transaction units 2181. Thus, bytes 38 to 42 may include another format header 2181A-1 for the second write transaction, and bytes 43 to 62 may include 20 bytes of write data for the second write transaction (indicated as D0 CH0 to D19 CH0). The second write transaction may be, for example, comprised of a format header 2181A-1. Fig. 20 The write request information may be generated and / or transmitted by the packetization logic 1955-4 and / or the D2D transmission and / or reception module 1951-4, for example, as a stream of one or more raw format transaction units 2080. Additionally or alternatively, Fig. 20 The raw format transaction unit 2080 shown in FIG. 20 may be configured to include write request information for more than one write transaction on channel CH0.

[0251] As with the first write transaction, the second write transaction may include 32 bytes of write data. However, because only the first 20 bytes of write data for the second write transaction can be accommodated in the space remaining for write data for CH0 in the raw format transaction unit 2181, the remaining 12 bytes of write data for the second write transaction may be packaged as the first 12 bytes of a second instance of the raw format transaction unit 2181, which may be generated and / or transmitted, for example, as a second transaction unit in a stream of transaction units.

[0252] In other cases, the amount of write data associated with the first write transaction may exceed the amount of space allocated for write data for CH0 in the raw format transaction unit 2181. In this case, the write data associated with the first write transaction (e.g., D0 CH0, ..., Dn-1 CH0, where the first write transaction includes n bytes of write data) may be packaged into second, third, or more raw format transaction units 2181, which may be generated and / or transmitted by the packaging logic 1955-0 and / or the D2D transmission and / or reception module 1951-0, for example, as a stream of transaction units.

[0253] For purposes of illustration, the portion of the raw format transaction unit 2181 allocated to write data information for channels CH1 to CH3 may include write data for a write transaction having the same amount of write data as CH0 (e.g., 32 bytes). However, in other cases, any write transaction for any channel may include any amount of write data. One or more of the write transactions for channels CH1 to CH3 may be Fig. 20 The write data of one or more of the write transactions for channels CH1 to CH3 may be accompanied by a corresponding format header 2181A in a manner similar to the write transaction for channel CH0.

[0254] In some embodiments, the raw format transaction unit 2181 may include data reliability information to implement one or more data reliability features. Fig.21 In the embodiment shown in , byte 31 may include an error correction code (ECC) identified as ECC0 CH0, which may provide error correction for bytes 0 to 30. ECC0 CH0 may be calculated across bytes 0 to 30 using data reliability logic (e.g., ECC logic) that may be located, for example, in packing logic 1955-0. Error correction code ECC0 CH0 may be included in a raw format transaction unit 2181 that may be sent to another die, where corresponding unpacking logic may use error correction code ECC0 CH0 to detect and / or correct errors in bytes 0 to 30. In a similar manner, bytes 32 to 62 may be protected by ECC1 CH0 located in byte 63. Additionally or alternatively, a portion of the raw format transaction unit 2181 allocated to write data information for channels CH1 to CH3 may be protected by ECC0 CH1, ECC1 CH1, ECC0 CH2, ECC1CH2, ECC0 CH3, and / or ECC1 CH3.

[0255] Although the use of error correction codes and / or other data reliability features with raw format transaction units according to example embodiments of the present disclosure is not limited to any particular application, it may be particularly beneficial, for example, in applications that may be sensitive to latency. For example, in some embodiments, a link layer or adapter layer of a D2D system may implement a retry scheme in which a transaction unit may be resent based on detection of a transmission error (e.g., using a CRC scheme). However, resending a transaction unit may result in unacceptable latency in some applications, such as high bandwidth memory (HBM).

[0256] The protocol conversion scheme can be transmitted by using the PHY layer of the D2D system Fig.21 The raw format transaction unit 2181 shown in FIG. 2 can be used to reduce this delay, thereby bypassing the link layer or adapter layer and avoiding the associated retry mechanism. However, in some example embodiments, the PHY layer of the D2D system may have a bit error rate (BER) of approximately 10 to 15, which may be unacceptably high in a system (e.g., at a system level) where a BER of approximately 10 to 25 may be expected. However, Fig.21 The ECC bytes shown in FIG. 1 can be used to correct one or more errors in a transaction unit, thereby improving the BER, while still using the relatively low latency original format transmitted through the PHY layer. Therefore, depending on the implementation details, the ECC scheme (such as, Fig.21 The ECC scheme shown in FIG. 4 ) may enable a protocol conversion scheme to transmit OD protocol information with relatively low latency over a D2D system using the original format while still maintaining an acceptably low BER.

[0257] In some embodiments, including Fig. 20 The format header 2080A shown in Fig.21 The SEQ NUM information in the format header 2181A shown in FIG. 1 and / or the SEQ NUM information used with any other embodiment disclosed herein may be used to implement a credit mechanism that, depending on implementation details, may reduce delays associated with the protocol conversion scheme. For example, referring to Figure 1 , the initiator 101 may initiate a write transaction by sending a write request to the target 102. Figure 4 In some embodiments, in a write request channel (e.g., Fig. 20 , AW channel in the embodiment shown in , may involve waiting for an asserted AWREADY signal from the target. However, receiving the AWREADY signal at the initiator 101 may involve round trip delays associated with the protocol information (e.g., signal operations (such as signal states, timing, modes, etc.)) packaged, sent, and / or unpacked in both directions, and therefore, the AWREADY signal from the target may be received with a relatively long delay. Similar delays may be associated with writing data channels (e.g., Fig.21The ready signal is associated with a WREADY signal on the W channel (for example, the W channel in the embodiment shown in the figure) and a ready signal on the write response channel (for example, the BREADY signal on the B channel), a ready signal on the read request channel (for example, the ARREADY signal on the AR channel), a ready signal on the read data channel (for example, the RREADY signal on the R channel), etc.

[0258] In some embodiments, the SEQ NUM information included in the format header may be used to implement a credit mechanism in which an initiator may initiate a first transaction and initiate a second transaction before receiving a ready signal associated with the first transaction. For example, in some embodiments, sequence numbers, credit information, etc. may be assigned to a transaction and / or one or more transaction units associated with a transaction and stored in a SEQ NUM field of one or more transaction units for a transaction. Thus, in the above example, when an asserted AWREADY signal is received from the target 102 at the initiator 101, the AWREADY signal may be matched to the transaction associated with the ready signal. Additionally or alternatively, the SEQ NUM information may be used to track the number of initiated transactions that have not yet completed, for example to prevent the initiation of additional transactions when a specified number of transactions have been initiated but not yet completed.

[0259] Depending on implementation details, a credit mechanism using the SEQ NUM information included in the format header may reduce latency, for example, by enabling one or more additional transactions to proceed while waiting for a ready signal for a first transaction.

[0260] In some embodiments, for example, assuming that the same write strobe pattern may be used for each WDATA transfer of a write transaction (e.g., all data transfers associated with the rising edge of clock cycles X to X+n-1), the WSTRB information may be used to establish a write strobe pattern for the WDATA signal that may be used for the first transfer and / or subsequent transfers on the WDATA signal. Additionally or alternatively, the WSTRB ON / OFF field may be set to a first state that may indicate that the WSTRB field is being used, or to a second state that may indicate that the WSTRB field may be ignored (e.g., all bits of the WDATA signal may be used to transfer write data). In some other embodiments, the WSTRB field may be used in conjunction with, for example, Figure 4 The dashed signal transitions in FIG. 1 and FIG. 2 are used together with each WDATA transfer shown in FIG. 1 , and the resulting data can be packaged as write data accordingly (e.g., D0 CH0, D1 CH0, ...). Depending on the implementation details, this can reduce overhead, reduce power consumption, reduce latency, increase bandwidth, increase throughput, etc.

[0261] Fig. 22An example embodiment of a transaction unit for transmitting write data information using a flit format according to an example embodiment of the present disclosure is shown. Fig. 22 References to this document can also be made to Figure 31. Fig. 22 The flit format transaction unit 2282 shown in FIG. 2 may be used, for example, with a component architecture such as Fig.12 , Fig.13 , Fig.16 , Fig.17 and / or Fig.19 The present invention may be used in conjunction with one of the component architectures shown and / or described herein, in which control information may be transmitted using a first D2D path, module, etc. and data information may be transmitted using a second D2D path, module, etc.

[0262] For illustrative purposes, Fig. 22 The flit format transaction unit 2282 shown in FIG. 2 may be described in the context of a system in which write data information for four OD interface channels CH0, . . . , CH3 may be written using a format such as Fig.19 In some embodiments, the write data information for one or more (e.g., twelve) additional OD interface channels CH4, ..., CH15 may be packaged as one or more (e.g., three) additional instances of the flit format transaction unit 2282, and the write data information for one or more (e.g., twelve) additional OD interface channels CH4, ..., CH15 may be packaged as one or more (e.g., three) additional instances of the flit format transaction unit 2282. Fig.19 , and / or the associated D2D transmission and / or reception modules 1951-1, ..., 1951-3. However, Fig. 22 The flit format transaction unit 2282 shown in is not limited to use with the numbers and / or types of information, signals, bits, bytes, channels, components, etc. disclosed herein.

[0263] The flit format transaction unit 2282 may use the flit format (such as Fig. 9oriented (e.g., latency-optimized) flit format shown and / or described). Thus, the flit format transaction unit 2282 may include two flit header bytes FLH B0 and FLH B1, which may be located at bytes 0 and 1, respectively. Additionally or alternatively, the flit format transaction unit 2282 may include CRC bytes CRC0 B0, CRC0 B1, CRC1 B0, and / or CRC1B1, which may be located at bytes 126, 127, 254, and / or 255, respectively. In some embodiments, one or more of the flit header bytes and / or CRC bytes may be specified by the D2D protocol and / or implemented as part of, for example, an adapter or link layer. In some embodiments, one or more of the flit header bytes and / or CRC bytes may be used to implement a retry mechanism. Thus, in some embodiments, because the retry mechanism may provide sufficient BER, the flit format transaction unit 2282 may omit other data reliability information (such as, Fig.21 In other embodiments, the flit format transaction unit 2282 may include additional data reliability information (such as, ECC information).

[0264] The flit format transaction unit 2282 may use a format header 2282A, which may be similar to Fig.21 21. For example, the format header 2282A may include one or more fields WVALID, WLAST, and / or WSTRB, which may use, for example, the nomenclature set forth in Table 1. Additionally or alternatively, the format header 2282A may include one or more fields WSTRB ON / OFF and / or SEQ NUM, which may use, for example, the nomenclature set forth in Table 2.

[0265] The write data for OD interface channels CH0, ..., CH3 may be packaged in an interleaved manner into flit format transaction units 2282, for example, Fig. 22 As shown in FIG, format header and / or write data information for one or more (e.g., each) of CH0, ..., CH3 are interleaved on a row of the flit format transaction unit 2282. For example, the first byte of the format header 2282A for each of channels CH0, CH1, CH2, and CH3 (e.g., bytes FHB0 CH0, FHB0 CH1, FHB0 CH2, and FHB0 CH3) may be located at bytes 2, 3, 4, and 5, respectively. As another example, the first byte of write data for each of channels CH0, CH1, CH2, and CH3 (e.g., bytes D0 CH0, D0 CH1, D0 CH2, and D0 CH3) may be located at bytes 22, 23, 24, and 25, respectively.

[0266] For illustrative purposes, Fig. 22 In the example embodiment shown in FIG. 1 , each transaction for each OD interface channel may include 32 bytes of read data, but in other embodiments, any transaction on any channel may include any amount of read data.

[0267] The flit format transaction unit 2282 may be used, for example, to transmit write data information for one or more write transactions that may be performed by using Fig. 20 One or more write requests are initiated by the original format transaction unit 2080 shown in FIG.

[0268] In some embodiments, and depending on implementation details, Fig. 22 The flit format transaction unit 2282 shown in the figure can reduce one or more aspects of latency by, for example, enabling a first portion of write data for one or more transactions on one or more OD interface channels (e.g., write data bytes D0 CH0 to D25 CH3 preceding the first CRC bytes CRC0 B0, CRC0 B1) to be delivered and potentially checked for errors before other portions of the write data for the one or more transactions.

[0269] Fig.23 An example embodiment of a transaction unit for transmitting write response information using a raw format according to an example embodiment of the present disclosure is shown. Fig.23 References to this document can also be made to Figure 32. Fig.23 The raw format transaction unit 2383 shown in FIG. 2 may be used, for example, with a component architecture (e.g., see Fig.12 , Fig.13 , Fig.16 , Fig.17 and / or Fig.19 The present invention may be used in conjunction with one of the component architectures shown and / or described herein, in which control information may be transmitted using a first D2D path, module, etc. and data information may be transmitted using a second D2D path, module, etc.

[0270] For illustrative purposes, Fig.23 The raw format transaction unit 2383 shown in FIG. 23 may be described in the context of a system in which write response information for one or more channels may be transmitted using, for example, Fig.19 The depacketization logic 1956-4 and / or D2D transmission and / or reception module 1951-4 shown in FIG. 1 may be used to receive and / or depacketize the packet. Fig.23 The raw format transaction unit 2383 shown in is not limited to use with the numbers and / or types of information, signals, bits, bytes, channels, components, etc. disclosed herein.

[0271] The raw format transaction unit 2383 may include a plurality of bytes that may be based on a plurality of OD interface channels (in this example, 32 channels indicated as channels CH0 to CH31) and / or a plurality of bytes in the format header 2383A (in this example, four bytes indicated as FHB0 to FHB3). Fig.23 In the embodiment shown in FIG. 2 , the raw format transaction unit 2383 may be packaged with a format header 2383A for each of the channels CH0 to CH31. Thus, the raw format transaction unit 2383 may include 128 bytes of format header information. For example, four bytes of format header information for CH0 may be located at bytes 0 to 3, four bytes of format header information for CH1 may be located at bytes 4 to 7, and so on.

[0272] In some embodiments, the raw format transaction unit 2383 may also include a Fig.21 Data reliability information of an error correction scheme similar to the described error correction scheme (such as ECC information indicated as ECC B0 to ECC B4).

[0273] The format header 2383A may include one or more fields indicated as BVALID, BRESP, BUSER, and / or BID, which may use the nomenclature set forth in Table 1 and may include fields that the unpack logic 1956-4 may use to generate a write response channel (e.g., Fig.19 A reconstructed version of the write response information (such as, Figure 4 The write response (eg, signal operation (such as signal state, timing, mode, etc.)) shown in FIG.

[0274] One or more of the format headers 2383A may be, for example, a Fig. 20 The write transaction initiated by the write request information in the original format transaction unit 2080 shown in FIG. 1 provides a write response, and / or write data can be used for the write transaction using Fig.21 The original format transaction unit 2181 and / or Fig. 22 The flit format transaction unit 2282 shown in is transmitted. Fig.19 The unpack logic 1956-4 at the initiator device shown in FIG. 1950 may receive raw format transaction units 2383 from corresponding packing logic (eg, similar to packing logic 1955-4) at a target device located at another die, for example, over a D2D interface 1913-4.

[0275] In some embodiments, one or more of the format headers 2383A may include a field indicated as SEQNUM as set forth in Table 2, which may be used to implement the same as described above with respect to Fig.21 The credit mechanism described is similar to the credit mechanism.

[0276] In some embodiments, and depending on implementation details, Fig.23 The raw format transaction unit 2383 shown in the figure can reduce overhead, reduce power consumption, reduce latency, increase bandwidth, increase throughput, etc., for example, by separating write response information from write data and / or read data transmission, by efficiently packaging write responses for multiple transactions and / or OD interface channels into one transaction unit (or a stream of one or more transaction units), by avoiding retry mechanisms, etc.

[0277] Fig.24 An example embodiment of a transaction unit for transmitting read request information using a raw format according to an example embodiment of the present disclosure is shown. Fig.24 References to this document can also be made to Figure 33. Fig.24 The raw format transaction unit 2484 shown in FIG. 24 can be used, for example, with a component architecture (such as, for example, referring to Fig.12 , Fig.13 , Fig.16 , Fig.17 and / or Fig.19 The present invention may be used in conjunction with one of the component architectures shown and / or described herein, in which control information may be transmitted using a first D2D path, module, etc. and data information may be transmitted using a second D2D path, module, etc.

[0278] For illustrative purposes, Fig.24 The raw format transaction unit 2484 shown in Fig.19 , in which control information for sixteen OD interface channels CH0, ..., CH15 may be packaged and / or transmitted using packaging logic (such as, packaging logic 1955-4) and / or associated D2D transmission and / or reception module 1951-4. However, Fig.24 The raw format transaction unit 2484 shown in is not limited to the number and / or type of information, signals, bits, bytes, channels, etc. disclosed herein.

[0279] In some respects, Fig.24 The structure and / or operation of the raw format transaction unit 2484 shown in Fig. 20, and one or more fields, signals, etc. for read requests replace one or more fields, signals, etc. for write requests. Thus, each row of the raw format transaction unit 2484 may include a two-byte format header 2484A and / or one or more fields (such as, ARID, ARADDR, ARLEN, ARQOS / ARREGION, and / or ARUSER using the nomenclature set forth in Table 1). In some embodiments, reliability information RELIABILITY may be included with and / or replace the ARUSER information. The format header 2484A may include one or more fields (such as, ARVALID, ARPROT, ARCACHE, ARBURST, and / or ARSIZE) using the nomenclature set forth in Table 1.

[0280] Packaging logic (such as, Fig.19 The packing logic 1955-4 shown in FIG. 1955-4 may capture a read request channel (eg, Fig.19 The AR channel in the embodiment shown in FIG. 10A ) reads the requested information (for example, Figure 5 The signal operations shown in (such as, signal status, timing, mode, etc.) are described in detail, and the information is packaged in one or more rows of the raw format transaction unit 2484.

[0281] In some embodiments, the format header 2484A may include a SEQ NUM field as set forth in Table 2, which may be used to implement the same Fig.21 The credit mechanism described is similar to the credit mechanism.

[0282] Fig.25 An example embodiment of a transaction unit for transmitting read data information using a raw format according to an example embodiment of the present disclosure is shown. Fig.25 References to this document can also be made to Figure 34. Fig.25 The raw format transaction unit 2585 shown in FIG. 25 can be used, for example, with a component architecture (such as, for example, referring to Fig.12 , Fig.13 , Fig.16 , Fig.17 and / or Fig.19 The present invention may be used in conjunction with one of the component architectures shown and / or described herein, in which control information may be transmitted using a first D2D path, module, etc. and data information may be transmitted using a second D2D path, module, etc.

[0283] For illustrative purposes, Fig.25The raw format transaction unit 2585 shown in FIG. 25 can be described in the context of a system in which read data information for four OD interface channels CH0, ..., CH3 can be used as shown in FIG. Fig.19 In some embodiments, one or more (e.g., three) additional instances of the raw format transaction unit 2585 may be used to receive and / or unpack read data information for twelve additional OD interface channels CH4, ..., CH15, and the read data information for the twelve additional OD interface channels CH4, ..., CH15 may be used as shown in FIG. Fig.19 , 1956-3 and / or the associated D2D transmission and / or reception modules 1951-1, ..., 1951-3 are used to receive and / or depacketize. However, Fig.25 The raw format transaction unit 2585 shown in is not limited to use with the numbers and / or types of information, signals, bits, bytes, channels, components, etc. disclosed herein.

[0284] In some respects, Fig.25 The structure and / or operation of the raw format transaction unit 2585 shown in Fig.21 The raw format transaction unit 2581 for writing data information is shown in FIG. 21, while one or more fields, signals, etc. for reading data replace one or more fields, signals, etc. for writing data. Therefore, each portion of the raw format transaction unit 2585 for a specific OD interface channel CH0 to CH3 may include information such as a format header 2585A and / or read data for one or more transactions on the corresponding channel.

[0285] In some embodiments, the raw format transaction unit 2585 may also include a Fig.21 Data reliability information of an error correction scheme similar to the described error correction scheme (such as ECC information indicated as ECC0 CH0, ECC1 CH0, ..., ECC0CH3, ECC1 CH3).

[0286] For illustrative purposes, Fig.25 In the example embodiment shown in , each transaction may include 32 bytes of read data, but in other embodiments, any transaction on any channel may include any amount of read data.

[0287] In some embodiments, the format header 2585A may include one or more fields (such as RVALID, RLAST, RRESP, and / or RID) that may use the nomenclature set forth in Table 1. In some embodiments, the unpacking logic (such as Fig.19The unpack logic 1956-0 shown in FIG. 15 may use the information in the format header 2585A together with the corresponding read data (eg, D0 CH0, ..., D31 CH0) to generate a read data channel (eg, Fig.19 A reconstructed version of the read data on the R channel in the embodiment shown in FIG. Figure 5 The signal operations shown in (such as signal status, timing, mode, etc.)

[0288] In some embodiments, the format header 2585A may include a SEQ NUM field as set forth in Table 2, which may be used to implement the same Fig.21 The credit mechanism described is similar to the credit mechanism.

[0289] Fig.26 An example embodiment of a transaction unit for transmitting read data information using a flit format according to an example embodiment of the present disclosure is shown. Fig.26 References to this document can also be made to Figure 35. Fig.26 The flit format transaction unit 2686 shown in FIG. 26 can be used, for example, with a component architecture (such as, for example, Fig.12 , Fig.13 , Fig.16 , Fig.17 and / or Fig.19 The present invention may be used in conjunction with one of the component architectures shown and / or described herein, in which control information may be transmitted using a first D2D path, module, etc. and data information may be transmitted using a second D2D path, module, etc.

[0290] For illustrative purposes, Fig.26 The flit format transaction unit 2686 shown in FIG. 26 can be described in the context of a system in which read data information for four OD interface channels CH0, ..., CH3 can be used as shown in FIG. Fig.19 1950-0) and / or the associated D2D transmission and / or reception module 1951-0. In some embodiments, read data information for one or more (e.g., twelve) additional OD interface channels CH4, ..., CH15 may be unpacked from one or more (e.g., three) additional instances of the flit format transaction unit 2686, and the read data information for one or more (e.g., twelve) additional OD interface channels CH4, ..., CH15 may be received and / or unpacked using the unpacking logic (e.g., unpacking logic 1956-0) and / or the associated D2D transmission and / or reception module 1951-0 shown in FIG. Fig.19 The unpacking logic shown in (such as, unpacking logic 1956-1, ..., 1956-3) and / or the associated D2D transmission and / or reception modules 1951-1, ..., 1951-3 are used for unpacking and / or reception. However, Fig.26The flit format transaction unit 2686 shown in is not limited to use with the numbers and / or types of information, signals, bits, bytes, channels, components, etc. disclosed herein.

[0291] In some respects, Fig.26 The structure and / or operation of the flit format transaction unit 2686 shown in FIG. 2680 may be similar to Fig. 22 The original format transaction unit 2282 shown in FIG. 20 is replaced by one or more fields, signals, etc. for reading data instead of one or more fields, signals, etc. for writing data. For example, the flit format transaction unit 2686 may use the flit format (such as, for example, Fig. 9 oriented (e.g., latency optimized) flit format shown and / or described). Thus, the flit format transaction unit 2686 may include flit header bytes FLH B0 and FLH B1 and / or CRC bytes, which in some embodiments may be specified by the D2D protocol and / or implemented as part of, for example, an adapter or link layer. In some embodiments, one or more of the flit header bytes and / or CRC bytes may be used to implement a retry mechanism. Thus, in some embodiments, because the retry mechanism may provide sufficient BER, the flit format transaction unit 2686 may omit other data reliability information (such as, Fig.21 In other embodiments, the flit format transaction unit 2686 may include additional data reliability information (such as, ECC information).

[0292] The flit format transaction unit 2686 may use a format header 2686A, which may be similar to Fig.25 For example, the format header 2686A may include one or more fields RVALID, RLAST, RRESP, and / or RID, which may use the nomenclature set forth in Table 1, for example. Additionally or alternatively, the format header 2686A may include a SEQ NUM field as set forth in Table 2, which may be used to implement the same as described above with respect to Fig.21 The credit mechanism described is similar to the credit mechanism.

[0293] The read data for OD interface channels CH0, ..., CH3 may be packaged in an interleaved manner into flit format transaction units 2686, for example, Fig.26As shown in , the format header and / or read data information for one or more (e.g., each) of CH0, ..., CH3 are interleaved on a row of the flit format transaction unit 2686. For example, the first byte of the format header 2686A for each of channels CH0, CH1, CH2, and CH3 (e.g., bytes FH B0 CH0, FH B0 CH1, FH B0 CH2, and FH B0 CH3) may be located at bytes 2, 3, 4, and 5, respectively. As another example, the first byte of the read data for each of channels CH0, CH1, CH2, and CH3 (e.g., bytes D0 CH0, D0 CH1, D0 CH2, and D0 CH3) may be located at bytes 14, 15, 16, and 17, respectively.

[0294] For illustrative purposes, Fig.26 In the example embodiment shown in , each transaction for each OD interface channel may include 32 bytes of read data, but in other embodiments, any transaction on any channel may include any amount of read data.

[0295] The flit format transaction unit 2686 may be used, for example, to transmit read data information for one or more read transactions that may be used by Fig.24 One or more read requests are initiated by the original format transaction unit 2484 shown in FIG.

[0296] In some embodiments, and depending on implementation details, Fig.26 The flit format transaction unit 2686 shown in the figure can reduce one or more aspects of latency by, for example, causing the first portion of read data for one or more transactions on one or more OD interface channels (e.g., read data bytes D0 CH0 to D27 CH3 preceding the first CRC bytes CRC0 B0, CRC0 B1) to be delivered and potentially checked for errors before other portions of the read data for the one or more transactions.

[0297] Fig. 27 An example embodiment of a transaction unit for transmitting a write request and write data using an original format and a combined transmission path according to an example embodiment of the present disclosure is shown. Fig. 27 References to this document can also be made to Figure 36. Fig. 27 The raw format transaction unit 2787 shown in FIG. 27 can be used, for example, with a component architecture (such as, for example, Fig.10 , Fig.11 , Fig.14 , Fig.15 and / or Fig.18 The present invention is used in conjunction with one of the component architectures shown and / or described herein, in which control information and data information can be combined and transmitted using a common path.

[0298] For illustrative purposes, Fig. 27 The raw format transaction unit 2787 shown in FIG. 27 can be described in the context of a system in which write request information and write data information for four OD interface channels CH0, . . . , CH3 can be used as shown in FIG. Fig.18 1855-0) and / or the associated D2D transmission and / or reception module 1851-0. In some embodiments, one or more (e.g., three) additional instances of the raw format transaction unit 2787 may be used to package and / or transmit write request information and write data information for twelve additional OD interface channels CH4, ..., CH15, and the write request information and write data information for the twelve additional OD interface channels CH4, ..., CH15 may be used as shown in FIG. Fig.18 , and / or the associated D2D transmission and / or reception modules 1851-1, ..., 1851-3. However, Fig. 27 The raw format transaction unit 2787 shown in is not limited to use with the numbers and / or types of information, signals, bits, bytes, channels, components, etc. disclosed herein.

[0299] Fig. 27 Some aspects of the structure and / or operation of the raw format transaction unit 2787 shown in FIG. 27 may be similar to Fig.21 2181. For example, information for write transactions of four OD interface channels CH0, ..., CH3 may be packaged into four parts of a raw format transaction unit 2787, including bytes 0 to 63, bytes 64 to 127, bytes 128 to 191, and bytes 192 to 255, respectively.

[0300] However, Fig. 27 The raw format transaction unit 2787 shown in FIG. 27 may combine write request information with write data information in a format header 2787A. For example, the format header 2787A may include a channel for writing a request (such as, Fig.18 The write request channel may be similar to Figure 4 As another example, the format header 2787A may include a format for writing a data channel (such as, Fig.18 The write data channel can be similar to Figure 4According to implementation details, combining write request information with write data information in a common header, transaction unit, etc. can enable write request information and write data information for one or more transactions to be transmitted using a common D2D path, module, etc.

[0301] In some embodiments, the format header 2787A may include one or more fields (such as AWVALID, AWPROT, AWCACHE, AWBURST, AWSIZE, WVALID, WLAST, AWADDR, AWLEN, AWID, AWQOS, and / or WSTRB) that may use, for example, the nomenclature set forth in Table 1. Additionally or alternatively, the format header 2787A may include a WSTRB ON / OFF field as set forth in Table 2, which may be used, for example, to indicate whether the WSTRB field is used.

[0302] In some embodiments, the raw format transaction unit 2787 may also include a Fig.21 Data reliability information of an error correction scheme similar to the described error correction scheme (such as ECC information indicated as ECC0 CH0, ECC1 CH0, ..., ECC0CH3, ECC1 CH3).

[0303] Fig. 27 The raw format transaction unit 2787 shown in FIG. 27 may include a first format header 2787A-0 for a first write transaction on CH0 in bytes 0 to 15 and 32 bytes of write data D0 CH0, ..., D31 CH0 for the first write transaction in bytes 16 to 30 and bytes 32 to 48 (byte 31 may include ECC byte ECC0 CH0). The first 14 bytes of a second format header 2787A-1 for a second write transaction on CH0 may be located in bytes 49 to 62, and the remaining two bytes of the second format header 2787A-1 may be packaged as a second instance of the raw format transaction unit 2787 and transmitted as part of a stream of transaction units with the second instance of the raw format transaction unit 2787. (The bold line surrounding the second format header 2787A-1 remains open to indicate that the second format header 2787A-1 continues in the second transaction unit.) For illustrative purposes, Fig. 27 In the example embodiment shown in , each transaction for each OD interface channel may include 32 bytes of write data, but in other embodiments, any transaction on any channel may include any amount of write data.

[0304] Fig.28An example embodiment of a transaction unit for transmitting a write request and write data using a flit format and a combined transmission path according to an example embodiment of the present disclosure is shown. Fig.28 References to this document can also be made to Figure 37. Fig.28 The flit format transaction unit 2888 shown in FIG. 28 can be used, for example, with a component architecture (such as, for example, Fig.10 , Fig.11 , Fig.14 , Fig.15 and / or Fig.18 The present invention is used in conjunction with one of the component architectures shown and / or described herein, in which control information and data information can be combined and transmitted using a common path.

[0305] For illustrative purposes, Fig.28 The flit format transaction unit 2888 shown in FIG. 28 can be described in the context of a system in which write request information and write data information for four OD interface channels CH0, . . . , CH3 can be used as shown in FIG. Fig.18 In some embodiments, one or more (e.g., three) additional instances of the flit format transaction unit 2888 may be used to package and / or transmit write request information and write data information for twelve additional OD interface channels CH4, ..., CH15, and the write request information and write data information for the twelve additional OD interface channels CH4, ..., CH15 may be used as shown in FIG. Fig.18 , and / or the associated D2D transmission and / or reception modules 1851-1, ..., 1851-3. However, Fig.28 The flit format transaction unit 2888 shown in is not limited to use with the numbers and / or types of information, signals, bits, bytes, channels, components, etc. disclosed herein.

[0306] Fig.28 Some aspects of the structure and / or operation of the flit format transaction unit 2888 shown in FIG. 28 may be similar to Fig. 22 For example, the write data for OD interface channels CH0, ..., CH3 can be packaged into a flit format transaction unit 2888 in an interleaved manner, for example, as shown in FIG. Fig.28As shown in , format header and / or write data information for one or more of CH0, ..., CH3 are interleaved on rows of flit format transaction units 2288. For example, the first byte of the format header 2888A for each of channels CH0, CH1, CH2, and CH3 (e.g., bytes FHB0CH0, FHB0CH1, FHB0CH2, and FHB0CH3) may be located at bytes 2, 3, 4, and 5, respectively. As another example, the first byte of write data for each of channels CH0, CH1, CH2, and CH3 (e.g., bytes D0CH0, D0CH1, D0CH2, and D0CH3) may be located at bytes 66, 67, 68, and 69, respectively.

[0307] However, Fig.28 The flit format transaction unit 2888 shown in FIG. 28 can be similar to Fig. 27 2787A shown in FIG. 2788A, the write request information is combined with the write data information in the format header 2888A. Thus, in some embodiments, the format header 2888A may include one or more fields (such as AWVALID, AWPROT, AWCACHE, AWBURST, AWSIZE, WVALID, WLAST, AWADDR, AWLEN, AWID, AWQOS, and / or WSTRB) that may use, for example, the nomenclature set forth in Table 1. Additionally or alternatively, the format header 2888A may include a WSTRB ON / OFF field as set forth in Table 2, which may be used, for example, to indicate whether the WSTRB field is used.

[0308] In some embodiments, the flit format transaction unit 2888 may use a flit format (such as Fig. 9 oriented (e.g., latency optimized) flit format shown and / or described). Thus, the flit format transaction unit 2888 may include flit header bytes FLH B0 and FLH B1 and / or CRC bytes, which in some embodiments may be specified by the D2D protocol and / or implemented as part of, for example, an adapter or link layer. In some embodiments, one or more of the flit header bytes and / or CRC bytes may be used to implement a retry mechanism. Thus, in some embodiments, because the retry mechanism may provide sufficient BER, the flit format transaction unit 2888 may omit other data reliability information (such as, Fig.21 In other embodiments, the flit format transaction unit 2888 may include additional data reliability information (such as, ECC information).

[0309] In some embodiments, and depending on implementation details, one or more of the techniques, schemes, etc. disclosed herein may provide a flexible scheme for converting between one or more OD protocols and one or more D2D protocols, for example by providing various transaction unit formats (e.g., raw format, flit format, etc.), component architectures, control options (e.g., write enable control options), credit mechanisms, reliability features (e.g., ECC technology), etc.

[0310] Any of the functions and / or components disclosed herein (including any of the interfaces, conversion logic, packing logic and / or unpacking logic, error detection logic, error correction logic, encoding logic and / or decoding logic, layers, etc.) may be implemented using circuit systems (such as combinational logic, sequential logic, timers, counters, registers, state machines, accelerators, embedded processors, microcontrollers, processing units (e.g., CPU, GPU, NPU, TPU, DSP), etc.), some of which may execute instructions stored in any type of memory and / or implement any type of execution environment (such as a container, a virtual machine, an operating system, etc. or a combination thereof).

[0311] Some embodiments disclosed above have been described in the context of various implementation details, but the principles of the present disclosure are not limited to these or any other specific details. For example, some functions have been described as being implemented by specific components, but in other embodiments, functions may be distributed between different systems and components in different locations and with various interfaces. Specific embodiments have been described as having specific processes, operations, etc., but these terms also cover embodiments in which specific processes, operations, etc. can be implemented with multiple processes, operations, etc., or embodiments in which multiple processes, operations, etc. can be integrated into a single process, step, etc. References to components or elements may refer only to a portion of a component or element. For example, references to blocks may refer to the entire block or one or more sub-blocks. Unless otherwise clear from the context, terms such as "first" and "second" used in the present disclosure and claims may only be used to distinguish the purpose of the elements they modify, and may not indicate any spatial or temporal order. In some embodiments, references to elements may refer to at least a portion of an element, for example, "based on" may refer to "based at least in part on", etc. References to the first element may not imply the existence of a second element. The principles disclosed herein have independent utility and may be embodied separately, and not every embodiment may apply every principle. However, these principles can also be embodied in various combinations, some of which can amplify the benefits of the individual principles in a synergistic manner. The various details and embodiments described above can be combined to produce additional embodiments according to the inventive principles of this patent disclosure.

[0312] In some embodiments, a portion of an element may refer to less than the element or the entire element. A first portion of an element and a second portion of an element may refer to the same portion of an element. A first portion of an element and a second portion of an element may overlap (e.g., a portion of the first portion may be the same as a portion of the second portion).

[0313] Since the inventive principles of this patent disclosure may be modified in arrangement and detail without departing from the inventive concept, such changes and modifications are considered to be within the scope of the appended claims.

Claims

1. An electronic device, comprising: A die comprising at least one circuit, wherein the at least one circuit is configured to: receiving first information using a first channel of the on-die interface; receiving second information using a second channel of the on-die interface; generating one or more transaction units including first information and second information; and The one or more transaction units are sent using at least one die-to-die system.

2. The electronic device according to claim 1, wherein: A first transaction unit of the one or more transaction units includes at least a portion of the first information; and A second transaction unit of the one or more transaction units includes at least a portion of the second information.

3. The electronic device according to claim 1, wherein: One of the one or more transaction units includes at least a portion of the first information and at least a portion of the second information.

4. The electronic device according to claim 1, wherein: The first information includes information for a first transaction of the on-die interface and information for a second transaction of the on-die interface.

5. The electronic device according to claim 4, wherein: The second information includes information for the first transaction of the on-die interface and information for the second transaction of the on-die interface.

6. The electronic device according to claim 1, wherein: The at least one die-to-die system includes a path, and The at least one circuit is configured to: sending at least a portion of the first information using the path; and At least a portion of the second information is sent using the path.

7. The electronic device according to claim 6, wherein: The at least a portion of the first information includes first control information; and The at least a portion of the second information includes second control information.

8. The electronic device according to claim 6, wherein: The at least a portion of the first information comprises first data information; and The at least a portion of the second information includes second data information.

9. The electronic device according to claim 1, wherein: The at least one die-to-die system includes a first path and a second path, and The at least one circuit is configured to: Sending at least a portion of the first information using the first path; and At least a portion of the second information is sent using a second path.

10. The electronic device according to claim 9, wherein: The at least a portion of the first information includes first control information; and The at least a portion of the second information includes second control information.

11. The electronic device according to claim 9, wherein: The at least a portion of the first information includes first data information; and The at least a portion of the second information includes second data information.

12. The electronic device according to any one of claims 1 to 11, wherein: One of the one or more transaction units includes error correction information for at least one of the one or more transaction units.

13. An electronic device, comprising: A die comprising at least one circuit, wherein the at least one circuit is configured to: receiving, using at least one on-die interface, first information for a first transaction; receiving second information for a second transaction using the at least one on-die interface; generating one or more transaction units including first information and second information; and The one or more transaction units are sent using at least one die-to-die system.

14. The electronic device according to claim 13, wherein: One of the one or more transaction units includes at least a portion of the first information and at least a portion of the second information.

15. The electronic device according to claim 14, wherein: The at least a portion of the first information includes control information for the first transaction; and The at least a portion of the second information includes control information for the second transaction.

16. The electronic device according to claim 14, wherein: The at least a portion of the first information includes data information for a first transaction; and The at least a portion of the second information includes data information for a second transaction.

17. The electronic device according to claim 13, wherein: The at least one die-to-die system includes a path, and The at least one circuit is configured to: sending at least a portion of the first information using the path; and At least a portion of the second information is sent using the path.

18. The electronic device according to claim 13, wherein: The at least one die-to-die system includes a first path and a second path, and The at least one circuit is configured to: Sending at least a portion of the first information using the first path; and At least a portion of the second information is sent using a second path.

19. The electronic device according to any one of claims 13 to 18, wherein: One of the one or more transaction units includes error correction information for at least one of the one or more transaction units.

20. An electronic device, comprising: A die comprising at least one circuit, wherein the at least one circuit is configured to: receiving first information using a first on-die interface; receiving second information using a second on-die interface; generating one or more transaction units including first information and second information; and The one or more transaction units are sent using at least one die-to-die system.

Images