Adaptive Chip-to-Chip Interface Protocol Architecture

Abstract

Embodiments herein describe using an adaptive chip-to-chip (C2C) interface to interconnect two chips, where the adaptive C2C interface includes circuitry for implementing multiple different C2C protocols to communicate with other chips. One or both of the chips in the C2C connection can include an adaptive C2C interface. During boot time, the adaptive C2C interface is configured to implement one of the different C2C protocols. During run-time, the chip then communicates with the other chip in the C2C connection using the selected C2C protocol.

Description

[Technical field]

[0001] Examples of the present disclosure generally relate to an adaptive chip-to-chip (C2C) interface capable of supporting multiple different protocols. [Background technology]

[0002] As technology evolves, instead of using a single IC chip that contains all components and provides all functionality, recent design methods have split the IC into one or more chiplets coupled to a common anchor IC. A chiplet comprises an IC that is specifically designed to be integrated with additional chiplets and an anchor IC to perform the functionality of the larger IC. Chipmakers can split a larger IC into chiplets and utilize the chiplets to perform specific functions or provide functionality to the IC when connected to an anchor. The chiplets may be hardwired to their respective locations on or relative to the anchor. This chiplet-based architecture decouples the development cycle of the anchor IC from the chiplets, since the chiplets and anchor ICs can be manufactured separately, rather than the entire integrated circuit being manufactured on a single larger piece of silicon.

[0003] Building larger devices using chiplets is an emerging technology, a key part of which is chip-to-chip (C2C) interface technology, such as that based on the Joint Electron Device Engineering Council (JEDEC) high bandwidth memory (HBM3) standard. C2C interfaces are optimized for short-distance physical connections over a medium such as a silicon interposer or equivalent.

[0004] A typical multi-chip system includes an anchor chip connected to several chiplets. The anchor often includes common blocks such as a processor subsystem (PS), memory subsystem (DDR controller), etc. The chiplets may include dedicated logic such as a data processing engine or high bandwidth memory. One advantage of a chiplet-based architecture is that it decouples the development cycle of the anchor from the chiplets. This allows vendors to mix and match different versions of the anchor and chiplets in a plug-and-play manner. However, this assumes that the anchor and chiplets implement the same C2C interface protocol. Summary of the Invention

[0005] One embodiment describes an IC die including an adaptive chip-to-chip (C2C) interface that includes circuitry for supporting a plurality of different C2C protocols. The IC die is configured to configure the adaptive C2C interface to implement only one of the plurality of different C2C protocols for communicating with an external IC die during boot time. The IC die also includes processing circuitry coupled to the adaptive C2C interface and configured to communicate with the external IC die using the adaptive C2C interface during run time, the IC die and the external IC die being components of a chip-to-chip configuration.

[0006] Another embodiment described herein is a system including a first IC die including a hardened C2C interface including circuitry for supporting only a first C2C protocol, and a second IC die connected to the first IC die, where one of the first IC die and the second IC die is an anchor and the other is a chiplet. Further, the second IC die includes an adaptive C2C interface including circuitry for supporting a plurality of different C2C protocols. The second IC die is configured to configure the adaptive C2C interface during runtime to implement only the first C2C protocol to communicate with the hardened C2C interface in the first IC die.

[0007] Another embodiment described herein is a system including a chiplet including a first adaptive C2C interface having circuitry for supporting a plurality of different C2C protocols, the chiplet configured to configure the first adaptive C2C interface to implement only a first C2C protocol of the plurality of different C2C protocols during runtime. The system also includes an anchor connected to the chiplet and including a second adaptive C2C interface having circuitry for supporting the plurality of different C2C protocols. The anchor is configured to configure the first adaptive C2C interface to implement only the first C2C protocol for communicating with the first adaptive C2C interface in the chiplet during runtime.

[0008] In a manner in which the above-recited features may be understood in detail, a more particular description briefly summarized above may be made by reference to exemplary implementations, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only typical example implementations and therefore should not be considered as limiting the scope thereof. [Brief description of the drawings]

[0009] [Figure 1A] 1 illustrates the use of an adaptive C2C interface to communicate between chips, according to an example. [Figure 1B] 1 illustrates the use of an adaptive C2C interface to communicate between chips, according to an example. [Diagram 2] 1 illustrates different communication schemes that may be supported by an adaptive C2C interface, according to an example. [Diagram 3] 1 illustrates a circuit within an adapted C2C interface, according to an example. [Figure 4] 1 illustrates coarse-grained and fine-grained configurations for an adaptive C2C interface, according to an example. [Diagram 5] 1 illustrates an optional circuit in an adaptive C2C interface, according to an example. [Figure 6] 1 illustrates a circuit within an adapted C2C interface, according to an example. [Figure 7] 1 includes a table of C2C protocols that may be supported by an adaptive C2C interface, according to one example. [Figure 8] 4 illustrates a control signal for merging bits in a received data word according to an example. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Various features are described below with reference to the drawings. It should be noted that the drawings may or may not be drawn to scale, and elements of similar structure or function are represented by similar reference numerals throughout the drawings. It should be noted that the drawings are intended only to facilitate the description of features. They are not intended as an exhaustive description of features or as limitations on the scope of the claims. In addition, the illustrated examples do not necessarily have all aspects or advantages shown. An aspect or advantage described in connection with a particular embodiment is not necessarily limited to that embodiment and can be implemented in any other embodiment, even if not so illustrated or explicitly described.

[0011] Embodiments herein describe the use of an adaptive C2C interface to interconnect two chips (also referred to interchangeably as IC dies) (e.g., two field programmable gate arrays (FPGAs), two application specific integrated circuits (ASICs), two systems on chips (SoCs), or an anchor and one or more chiplets (e.g., high bandwidth memory (HBM)). One or both of the chips in the C2C connection may include an adaptive C2C interface that supports multiple C2C protocols. For example, the adaptive C2C interface may support using one or more standard defined C2C protocols, such as Advanced eXtensible Interface-Streaming (AXIS) or Compute eXpress Stream (CXS), or a proprietary C2C protocol. Additionally, the adaptive C2C interface may support different options for the standard C2C protocol, such as supporting parity in the CXS protocol.

[0012] At boot time, the adaptive C2C interface is configured to support the same C2C protocol used by the other chip. For example, one chip can have a hardened (non-adaptive) C2C interface that supports only one protocol (e.g., AXIS), and the other chip has an adaptive C2C interface that can support AXIS, CXS, or proprietary C2C protocols. At boot time, the chip with the adaptive C2C interface has its adaptive C2C interface configured to implement the AXIS protocol, thereby allowing the two chips to communicate using the same protocol. In this way, the same chip (with an adaptive C2C interface) can be connected to a different chip with a hardened C2C interface that uses a different C2C protocol. In another example, both chips can have adaptive C2C interfaces, in which case the system designer can choose which protocol to use and configure the adaptive C2C interface to support the selected protocol.

[0013] 1A and 1B illustrate the use of an adaptive C2C interface 120 to communicate between chips, according to an example. FIG 1A illustrates a system 100 having chips 105A, 105B, and 105C. The chips 105 may be a mix of heterogeneous or homogeneous chips. The chips 105 may include any type of semiconductor chip or integrated circuit (IC), such as an FPGA, an ASIC, an SoC, an anchor die, or a chiplet (e.g., HBM).

[0014] Anchor and chiplet-based designs allow for the generation of larger circuits from smaller, replicated, or identical chiplets using a templated architecture. Chiplet is part of an overall IC design framework that performs one or more specific functions, but requires an external entity (i.e., anchor) to make the function useful. For example, a chiplet may perform acceleration of a machine learning function, but require an anchor to program its registers, provide an interface to memory, etc. Conversely, an anchor is configured as a superset of a traditional IC, since the specific functions required by the IC design framework are not present, but are left to the chiplet that is interfaced with the anchor. Not only does the anchor perform most of the functions of a traditional IC (e.g., CPU, memory controller, etc.), but the anchor also has logic to interface with at least one chiplet. In some examples, an anchor can interface with dozens of chiplets.

[0015] One advantage of adopting a chiplet / anchor architecture is that it decouples the development cycles of the anchor and the chiplet. For example, an anchor developer can develop and generate the anchor independently from the development of the chiplet. Instead, the anchor and the chiplet only adopt a clearly and consistently defined C2C interface to enable communication between the anchor and the coupled chiplet. This provides flexibility in creating device ICs based on the anchor and the chiplet. Furthermore, flexibility may be provided at different levels of granularity. For example, flexibility may include different chiplets in different arrangements, different mappings for communication between the chiplet and the anchor, etc.

[0016] In this embodiment, chip 105B (e.g., anchor) includes adaptive C2C interfaces 120A and 120B used to communicate with chips 105A and 105C (e.g., chiplets), respectively. The adaptive C2C interfaces 120 support multiple different C2C protocols. Each adaptive C2C interface 120 may support multiple standard C2C protocols (e.g., AXIS and CXS), one standard C2C protocol and a proprietary C2C protocol, or multiple standard C2C protocols and a proprietary C2C protocol. At boot time, the adaptive C2C interface 120 is configured to execute or implement one of the multiple C2C protocols supported by the interface 120.

[0017] In contrast, the chips 105A and 105C include hardened C2C interfaces 115A and 115B. The hardened C2C interfaces 115 may support or execute only one C2C protocol. For example, the hardened C2C interfaces 115A and 115B may execute the AXIS protocol. In that case, to enable communication between the chip 105B and the chips 105A and 105C, the adaptive C2C interface 120 is configured to also execute the AXIS protocol. Conversely, if the hardened C2C interfaces 115A and 115B execute a proprietary protocol instead, the adaptive C2C interface 120 is configured to also execute the proprietary protocol. Thus, as long as the hardened C2C interface 115 executes a C2C protocol that is one of the protocols supported by the adaptive C2C interface 120, the chips 105A to 105C can communicate. In this manner, adaptive C2C interface 120 can greatly increase the types of chips with which chip 105B can communicate, such as chips from different product generations or chips made by different vendors.

[0018] Chips 105A-105C also include respective processing circuits 110 that can communicate with processing circuits 110 in different chips using hardened C2C interface 115 and adaptive C2C interface 120. Processing circuits 110 may be the same or different in chips 105A-105C. For example, chip 105B may be an anchor chip, while chips 105A and 105C are chiplets performing the same function (e.g., HBM). In another example, chips 105A-105C may each include different types of processing circuits 110 (e.g., an anchor chip and two chiplets performing different functions, or three anchor chips). As non-limiting examples, processing circuits 110 may include a data processing engine, memory (e.g., HBM), memory controller, programmable logic, central processing unit (CPU), accelerator, etc.

[0019] Although not shown, connections between chips 105 may extend through an interposer, which will be described below.

[0020] FIG. 1B shows the same chip 105B from FIG. 1A connected to chips 105D and 105E, both of which include adaptive C2C interfaces. That is, unlike FIG. 1A, where one chip with an adaptive C2C interface 120 is connected to a chip with a hardened C2C interface 115, in FIG. 1B, chips 105B, 105D, and 105E all include adaptive C2C interfaces 120. The adaptive C2C interfaces 120A-120D may support the same set of C2C protocols or may support different sets of C2C protocols. As long as the set of C2C protocols supported by the adaptive C2C interfaces 120A-120D has at least one common C2C protocol, that common C2C protocol can be used to communicate between chips 105B, 105D, and 105E. Thus, a C2C connection can be formed between chips with adaptive C2C interfaces 120 as long as the interfaces 120 support at least one common C2C protocol.

[0021] 1A, chips 105B, 105D, and 105E of FIG. 1B each include a respective processing circuit 110. Processing circuit 110 can communicate with processing circuit 110 in different chips using adaptive C2C interfaces 120A-120D. Processing circuit 110 may be the same or different in chips 105B, 105D, and 105E.

[0022] FIG. 2 illustrates different communication methods that may be supported by an adaptive C2C interface, according to an example. Specifically, FIG. 2 illustrates four different methods for forming a C2C connection, where at least one chip (but possibly both) has an adaptive C2C interface. Furthermore, the chips 205, 210 are connected using an interposer 215 that provides electrical connections between the chips 205 and 210. In one embodiment, the chips 205, 210 are disposed on the same surface of the interposer 215 (e.g., a silicon interposer), but in other embodiments, the chips 205, 210 may be disposed on different sides (e.g., opposite sides) of the interposer 215. Although two chips (e.g., integrated circuits (ICs)) are shown, the interposer 215 may be used to connect three or more chips together (e.g., the three chips shown in FIG. 1A and FIG. 1B), either on the same surface or by using multiple surfaces on the interposer 215. Further, in all of the examples shown in FIG. 2, the same bus protocol (e.g., Open High Bandwidth Interface (OHBI), Bunch of Wires (BoW), or Advanced Interface Bus (AIB)) can be used to route data through interposer 215.

[0023] In one example, chip 205 is assumed to include an adaptive C2C interface capable of supporting AXIS, CXS, and proprietary C2C protocols. In contrast, chip 210 is assumed to include a hardened C2C interface. The top left example shows chip 210 using the AXIS protocol, where the adaptive C2C interface (not shown) in chip 205 is also configured to use the AXIS protocol. The top right example shows chip 210 using a customized AXIS protocol, where the adaptive C2C interface in chip 205 is also configured to use the customized AXIS protocol. The bottom left example shows chip 210 using the CXS protocol, where the adaptive C2C interface in chip 205 is also configured to use the CXS protocol. The bottom right example shows chip 210 using a proprietary protocol, where the adaptive C2C interface in chip 205 is also configured to use the proprietary protocol.

[0024] However, in another example, it is assumed that chips 205 and 210 both have adaptive C2C interfaces. If these interfaces have circuits that support AXIS, customized AXIS, CXS, and proprietary protocols, then the four schemes shown in Figure 2 are possible ways that chips 205 and 210 can be configured to communicate.

[0025] 3 shows the circuitry within the adaptive C2C interface 120, according to one example. In this example, the adaptive C2C interface 120 shows two data words (DW0 and DW1), but can have any number of DWs. DW1 is used to send data from the processing circuitry 110 within the chip 105 to the interposer and external chips, and DW0 is used to receive data from the interposer and external chips.

[0026] In this example, the adaptive C2C interface 120 supports three different types of C2C protocols: a first standard protocol 325 (e.g., AXIS or customized AXIS), a proprietary protocol 330, and a second standard protocol 335 (e.g., CXS or customized CXS). That is, the data paths for DW0 and DW1 (as well as any other DW channel in the interface 120) can support any of these three different C2C protocols. However, this is only one example. In other embodiments, the adaptive C2C interface 120 may support only two standard protocols, or the interface 120 may support only one of the standard protocol and the proprietary protocol 330.

[0027] As shown, the DW1 data path stores data received from the processing circuit 110 in a first in first out (FIFO) 305A and then forwards the data to a protocol de-multiplexer (de-mux) 310A. The protocol de-mux 310A selects which C2C protocol is implemented or used by the adaptive C2C interface 120 based on a selection signal. These mux selection signals can be set by registers, which are described below. In either case, the protocol de-mux 310A routes the data along a path that corresponds to the C2C protocol currently being executed by the adaptive C2C interface 120.

[0028] The adaptive C2C interface 120 also includes option circuitry 315A that allows a user to customize the standard protocols 325, 335 and the proprietary protocol 330. For example, a user may want to use a customized AXIS or CXS protocol, such as a customized AXIS that uses different TKEEP bits, or a customized CXS that has different parity bits. The option circuitry 315A includes multiplexers and processing circuits that allow the adaptive C2C interface 120 to support customized versions of the standard protocols 325, 335. Additionally, the option circuitry 315A may include circuitry to enable the adaptive C2C interface 120 to use the proprietary protocol 330. In one embodiment, unlike the standard protocols 325, 335, the proprietary protocol 330 does not initially assign any meaning to the wires used in the C2C connection. Instead, the adaptive C2C interface 120 allows a user to assign the meaning of the wires at boot time. In this manner, by using a proprietary data path, a user can assign any meaning he or she desires to the wire corresponding to DW1 (e.g., data word, timing word, identification word, parity word, etc.).

[0029] The data path for DW1 also includes protocol mux 320A, which outputs data received from any C2C protocol that adaptive C2C interface 120 is configured to implement. For example, if adaptive C2C interface 120 is currently configured to implement standard protocol 325, a select signal sent to protocol mux 320A causes it to output data received from the top data path. In this manner, data sent to the interposer and external chips using DW1 can be sent using one of the three C2C protocols supported by adaptive C2C interface 120.

[0030] The data path for DW0 is similar to the data path for DW1, but in reverse. In this case, when a data word is received from the interposer, protocol de-mux 310B routes the data on one of three data paths corresponding to the three C2C protocols currently being implemented by adaptive C2C interface 120, e.g., first standard protocol 325, proprietary protocol 330, or second standard protocol 335. The data bits then pass through option circuit 315B, which supports various customizations as described above. Finally, the data bits pass through protocol mux 320B and are stored in FIFO 305B before being sent to processing circuit 110.

[0031] In one embodiment, the data path for the DW used to transmit data to the interposer and external chips can use a different C2C protocol than the data path for the DW used to receive data. That is, the transmit DW and receive DW are independent of each other. For example, the adaptive C2C interface 120 can use a first standard protocol 325 (e.g., AXIS) to transmit DWs to the interposer and external chips, but can use a second standard protocol 335 (e.g., CXS) to receive DWs from the interposer and external chips.

[0032] Furthermore, circuits in the data paths corresponding to the C2C protocols not selected during boot time are not used during runtime. For example, if the adaptive C2C interface 120 was configured to use the first standard protocol 325 at boot time, the data paths corresponding to the proprietary protocol 330 and the second standard protocol 335 are not used during runtime. In one embodiment, for each DW, only one of the three data paths between the protocol mux 320 and the protocol de-mux 310 is used during runtime, and the other two data paths are not used during runtime.

[0033] FIG. 4 illustrates a coarse-grained configuration and a fine-grained configuration for an adaptive C2C interface, according to an example. In one embodiment, FIG. 4 illustrates a programmable model for programming an adaptive C2C interface during boot time. In this embodiment, the coarse-grained configuration 405 sets the C2C protocol used by a particular adaptive C2C interface. Continuing with the example of FIG. 3, the coarse-grained configuration 405 sets three different C2C protocols, namely, the first standard protocol 325, the second standard protocol 330, or the proprietary protocol 335. That is, during boot time, a user can set the coarse-grained configuration 405 to select one of the three C2C protocols.

[0034] As described above, the adaptive C2C interface can use different C2C protocols depending on the direction. Thus, the coarse-grained configuration 405 can set a different C2C protocol for a DW used to receive data than for a DW used to transmit data.

[0035] The fine-grained configuration 410 can customize the selected C2C protocol. For example, if the first standard protocol 325 is AXIS, the fine-grained configuration 410 can be used to set the DATA, TKEEP, TID, TUSER, and TDEST signals. As described in the following example, the number of bits used for these signals can be changed and therefore customized using the fine-grained configuration 410. In one embodiment, the fine-grained configuration 410 is used to select between different preset customizations of the first standard protocol 325. For example, an AXIS specification can define different customizations of AXIS. The fine-grained configuration 410 can then be used to select between those different customizations.

[0036] If the second standard protocol 330 is selected, the fine-grained configuration 410 can be used to customize the protocol 330. In this example, the second standard protocol 330 can be a CXS protocol where the fine-grained configuration 410 can customize the DATA, CTRL, and CHECK signals. In one embodiment, the CXS specification can define different customizations of CXS. The fine-grained configuration 410 can then be used to select between those different customizations.

[0037] In contrast, in this example, there are no preset customizations or signals for the proprietary protocol 335. In that case, the wires in the C2C protocol are not assigned any meaning or value. Instead, the fine-grained configuration 410 can provide meaning or assignments to the wires in the C2C interface. That is, the user can fully customize or set the values ​​of the wires in the C2C interface to support whatever proprietary protocol 335 is desired.

[0038] FIG. 5 illustrates an optional circuit 315B in an adaptive C2C interface, according to an example. That is, FIG. 5 illustrates an exemplary implementation of the optional circuit 315B introduced in FIG. 3. In this example, the optional circuit 315B is used in the receive path where the DATA and TKEEP signals are received from the interposer and the external chip. The optional circuit 315 includes a TKEEP processing circuit 510 and a bypass path 515 that bypasses the TKEEP processing circuit 510. For example, some customizations or implementations of AXIS perform TKEEP processing, while others do not. For an implementation or customization of AXIS that performs TKEEP processing in the adaptive C2C interface, a fine-grained configuration can set a select signal on mux 505 to output the input received from the TKEEP processing circuit 510. However, if the fine-grained configuration indicates that option circuitry 315A should not perform TKEEP processing, then the fine-grained configuration sets the select signal on mux 505 to output the input it receives from bypass path 515 .

[0039] In addition, option circuit 315B illustrates a VALID signal that can be received from the interposer and from an external chip. Option circuit 315B also illustrates a READY signal that can be sent to the interposer and from an external chip.

[0040] FIG. 6 illustrates a circuit within the adaptive C2C interface 120 according to an example. In this example, the adaptive C2C interface 120 includes a coarse register 610 that stores the coarse grain configuration described above. That is, the coarse register 610 stores information corresponding to the coarse grain configuration, such as which C2C protocol the adaptive C2C interface 120 is configured to use. Accordingly, the coarse register 610 outputs control signals to mux 310A, mux 320A, and the option circuit 315. These control signals can control the output of mux 310A and 320A, so that data is routed on a data path corresponding to the selected C2C protocol. In this example, the adaptive C2C interface 120 can support AXIS, CXS, and proprietary protocols.

[0041] The options circuitry 315 includes AXIS logic 615, Collection of Wires (COW) logic 620, and CXS logic 625. The AXIS and CXS logic 615, 625 are used when either the AXIS or CXS protocol is selected by the course register 610. The COW logic 620 is used when a proprietary protocol is selected by the course register 610. In one embodiment, the COW logic 620 does not assign meaning to the wires in the C2C interface; instead, the meaning is provided by the user to implement the proprietary protocol.

[0042] The adaptive C2C interface 120 also includes a fine register 605 that stores the fine-grained configuration described above. The fine register 605 outputs control signals to the AXIS logic 615, the COW logic 620, and the CXS logic 625. These control signals enable the adaptive C2C interface 120 to implement customizations of the AXIS and CXS protocols and to implement proprietary protocols by assigning meanings to the COWs in the C2C interface. Thus, in this example, the option circuit 315 includes separate logic or circuitry for the three C2C protocols supported by the adaptive C2C interface 120. In one embodiment, the control signal from the course register 610 indicates which of the three logics 615, 620, and 625 is active, while the control signal from the fine register 605 sets the customization for that logic (if any).

[0043] Thus, Figure 6 illustrates the use of coarse and fine registers 610 and 605 to implement the coarse and fine grained configurations described in Figure 4. Additionally, Figure 6 illustrates an example of a multi-level static multiplexing mechanism controlled by configuration registers (e.g., fine and coarse registers 605 and 610). The multiplexing in Figure 6 has three main aspects: demultiplexing the incoming DW into one of three protocols using mux 310A, multiplexing across various streaming protocols using mux 320A, and multiplexing options within the streaming protocols using AXIS logic 615, COW logic 620, and CXS logic 625 in option circuit 315.

[0044] In this embodiment, advantageously, protocol-specific resources such as FIFO 305 are not duplicated across different protocols. In a multi-level multiplexing scheme, the adaptive C2C interface can use a single resource (such as a single FIFO 305) at the output of the option multiplexing, thus reducing the gate count of the design.

[0045] In one embodiment, to reduce the amount of multiplexing, a limited range of programming may be implemented. For example, some chips may allow their adaptive C2C interface to support only coarse-level register programming, while other chips may allow their adaptive C2C interface to support only two options for fine-level register programming.

[0046] 7 illustrates a table of C2C protocols that may be supported by an adaptive C2C interface, according to an example. Table 705 illustrates a first customization or implementation of AXIS using the adaptive C2C interface 120, and table 710 illustrates a second customization or implementation of AXIS using the same adaptive C2C interface 120. That is, table 705 illustrates that the same adaptive C2C interface 120 may be configured at boot time to implement different customizations of AXIS.

[0047] Both the AXIS implementations shown in Table 705 and Table 710 allocate 256 bits for the DATA signal, 4 bits for the TUSER signal, and 4 bits for the TDEST signal. However, the AXIS implementations differ in that the implementation in Table 705 uses only 6 bits for the TKEEP signal, while the implementation in Table 710 uses 4 bits. Additionally, the implementation in Table 710 uses only 2 bits for the TID signal, while the implementation in Table 705 uses 4 bits. These different customizations of the AXIS protocol can be made possible using fine-grained configurations stored in fine registers 605 of FIG. 6.

[0048] 7 also includes table 715 showing a first customization or implementation of a CXS using the adaptive C2C interface 120, while table 720 shows a second customization or implementation of a CXS using the same adaptive C2C interface 120. Both the CXS implementations shown in table 715 and table 720 allocate 256 bits as DATA signals and 14 bits as control (CTRL) signals. However, the CXS implementations differ in that the implementation in table 715 does not use parity, while the implementation shown in table 720 allocates 34 bits as PARITY signals. These different customizations of the CXS protocol can be made possible using fine-grained configurations stored in the fine registers 605 of FIG. 6.

[0049] As another example customization that can be implemented, the adaptive C2C interface can be configured to support different flow control mechanisms for a selected C2C protocol, for example, the adaptive C2C interface can use a valid / ready flow control mechanism or a credit-based flow control mechanism for the selected C2C protocol.

[0050] FIG. 8 shows a control signal for merging bits in a received data word according to an example. When two DWs are received in the same direction, some of the fields in the DWs may be merged. Table 800 shows the fields in a DW for AXIS that may be merged with another DW received in the same direction. In this example, a "1" in the second column indicates that the field should be merged, and a "0" indicates that the fields in the two DWs do not need to be merged. For example, 256-bit DATA signals in two DWs should be merged to form a 512-bit DATA signal. Similarly, the bits of ECC, TKEEP, and CONFIG-1 signals may also be merged into one respective field.

[0051] In contrast, the TID, TUSER, TDEST, and CONFIG-2 signals do not need to be merged. Instead, the adaptive C2C interface can select one of the fields to propagate or carry forward while the corresponding field is dropped or ignored. For example, for fields that are not merged, the adaptive C2C can select a field from a lower DW to carry forward while the corresponding field in the higher DW is dropped.

[0052] In one embodiment, when the adaptive C2C interface is implementing its own C2C protocol and merging DWs received in the same direction, 276 bits of data in the two DWs are merged, but the control bits are not merged, i.e., the adaptive C2C interface can ignore the control bits from one of the two DWs.

[0053] In the foregoing, reference is made to the embodiments presented in this disclosure. However, the scope of the disclosure is not limited to the specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated for implementing and practicing the contemplated embodiments. Furthermore, the embodiments disclosed herein may achieve other possible solutions or advantages over the prior art, but whether or not a particular advantage is achieved by a given embodiment does not limit the scope of the disclosure. Thus, the above aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the appended claims unless expressly recited in the claims.

[0054] As will be appreciated by one of ordinary skill in the art, embodiments disclosed herein may be embodied as a system, method, or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be referred to generally herein as a "circuit," "module," or "system." Furthermore, aspects may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein.

[0055] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of computer readable storage media include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this specification, a computer readable storage medium is any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0056] A computer-readable signal medium may include a propagated data signal in which computer-readable program code is embodied, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium is not a computer-readable storage medium but may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0057] The program code embodied on the computer readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

[0058] Computer program code for carrying out operations of aspects of the present disclosure may be written in any combination of one or more programming languages, including, for example, object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program code may execute completely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, partially on a remote computer, or completely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider).

[0059] Aspects of the present disclosure are described below with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments presented in the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus such that the instructions, executed via a processor of the computer or other programmable data processing apparatus, cause a machine to create means for implementing the functions / acts specified in the blocks of the flowchart and / or block diagrams.

[0060] These computer program instructions may also be stored on a computer-readable storage medium, where the instructions stored on the computer-readable storage medium can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner to produce an article of manufacture including instructions that implement aspects of the functions / acts specified in the flowchart and / or block diagram blocks.

[0061] Computer program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be executed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, such that the instructions executing on the computer or other programmable apparatus provide a process for implementing the functions / acts specified in the flowchart and / or block diagram blocks.

[0062] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions described in the blocks may occur out of the order described in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flow diagram illustrations, as well as combinations of blocks in the block diagrams and / or flow diagram illustrations, may be executed by a dedicated hardware-based system that performs the specified functions or acts, or a combination of dedicated hardware and computer instructions.

[0063] While the above is directed to particular examples, other and further examples may be devised without departing from the basic scope thereof, which is determined by the following claims.

Claims

1. 1. An integrated circuit (IC) die comprising: an adaptive C2C interface comprising circuitry for supporting a plurality of different C2C protocols for communicating with an external IC die using a chip-to-chip (C2C) connection, the semiconductor chip being configured to configure the adaptive C2C interface during boot time to implement only one of the plurality of different C2C protocols for communicating with the external IC die; a processing circuit coupled to the adaptive C2C interface and configured to communicate with the external IC die using the adaptive C2C interface during runtime, wherein the IC die and the external IC die are components of a chip-to-chip configuration.

2. 2. The IC die of claim 1, wherein the plurality of different C2C protocols are streaming C2C protocols, a first streaming C2C protocol among the streaming C2C protocols being a standard defined protocol, and a second streaming C2C protocol among the streaming C2C protocols being a proprietary protocol.

3. The adapted C2C interface comprises: a demultiplexer (de-mux) having outputs coupled to data paths corresponding to the plurality of different C2C protocols, the de-mux being configured to select only one of the data paths as an output during run-time; a mux coupled as an input to the data paths and configured to select between one of the data paths for output to one of the external IC die or the processing circuitry, the adaptive C2C interface further comprising: and an option circuit disposed along the data path between the de-mux and the mux, the option circuit enabling the adaptive C2C interface to customize the plurality of different C2C protocols, the adaptive C2C interface comprising: a coarse register for storing a coarse grain configuration for controlling the de-mux and the mux to select only one of the data paths; 10. The IC die of claim 1, further comprising: a fine register for storing fine-grained configuration for controlling the option circuitry to customize the one of the plurality of different C2C protocols.

4. the adaptive C2C interface is configured to receive a first data word (DW) from the external IC die and to transmit a second DW to the external IC die; 2. The IC die of claim 1, wherein the adaptive C2C interface is configurable, at boot time, to use a first C2C protocol of the plurality of different C2C protocols to receive the first DW and to use a second different C2C protocol of the plurality of different C2C protocols to transmit the second DW.

5. 2. The IC die of claim 1, further comprising: a second adaptive C2C interface disposed on a different side of the IC die than the adapted C2C interface, the second adaptive C2C interface comprising circuitry for supporting the plurality of different C2C protocols, and the IC die configured to configure the second adaptive C2C interface during boot time to implement only one of the plurality of different C2C protocols to communicate with a second external IC die.

6. 6. The IC die of claim 1, 2, 3, 4, or 5, wherein the circuitry in the adaptive C2C interface corresponding to one of the plurality of different C2C protocols not selected during boot time is not used during runtime, and the IC die is one of an anchor or a chiplet in the chip-to-chip configuration.

7. 1. A system comprising: a first IC die having a hardened C2C interface comprising circuitry for supporting only a first C2C protocol; a second IC die connected to the first IC die, one of the first IC die and the second IC die being an anchor and the other being a chiplet, the second IC die comprising an adaptive C2C interface comprising circuitry for supporting a plurality of different C2C protocols, the second IC die configured to configure the adaptive C2C interface to implement only the first C2C protocol to communicate with the hardened C2C interface in the first IC die during boot time.

8. an interposer, wherein the hardened C2C interface and the adapted C2C interface communicate with each other through the interposer; 8. The system of claim 7, further comprising: a third IC die coupled to the interposer, the third IC die comprising a second hardened C2C interface comprising circuitry to support only the first C2C protocol, the second IC die comprising a second adaptive C2C interface comprising circuitry to support the plurality of different C2C protocols, the first IC die configured to configure the second adaptive C2C interface to implement only the first C2C protocol during boot time to communicate with the second hardened C2C interface in the third IC die via the interposer.

9. The IC die of claim 1 or the system of claim 7, wherein the plurality of different C2C protocols is a streaming C2C protocol.

10. 8. The system of claim 7, wherein the plurality of different C2C protocols are streaming C2C protocols, a first streaming C2C protocol among the streaming C2C protocols being a standard defined protocol, and a second streaming C2C protocol among the streaming C2C protocols being a proprietary protocol.

11. The adapted C2C interface comprises: a de-mux having outputs coupled to data paths corresponding to the plurality of different C2C protocols, the de-mux being configured to select only one of the data paths as an output during runtime; 10. The IC die of claim 1 or the system of claim 7, further comprising: a mux coupled as an input to the data paths and configured to select between one of the data paths for output to the first IC die.

12. The adapted C2C interface comprises: a de-mux having outputs coupled to data paths corresponding to the plurality of different C2C protocols, the de-mux being configured to select only one of the data paths as an output during runtime; a mux coupled as an input to the data paths and configured to select between one of the data paths for output to the first IC die; The adapted C2C interface comprises:

11. The system of claim 7, 8, or 10, further comprising an options circuit disposed along the data path between the de-mux and the mux, the options circuit enabling the adaptive C2C interface to customize the plurality of different C2C protocols.

13. 1. A system comprising: a chiplet comprising a first adaptive C2C interface comprising circuitry for supporting a plurality of different C2C protocols, the chiplet being configured to configure the first adaptive C2C interface during boot time to implement only a first C2C protocol of the plurality of different C2C protocols; an anchor connected to the chiplet, the anchor comprising a second adaptive C2C interface comprising circuitry for supporting the plurality of different C2C protocols, the anchor configured to configure the first adaptive C2C interface during boot time to run only the first C2C protocol for communicating with the first adaptive C2C interface in the chiplet.

14. 14. The system of claim 7 or claim 13, further comprising an interposer, the first adaptive C2C interface and the second adaptive C2C interface communicating with each other via the interposer.

15. an interposer, the first adaptive C2C interface and the second adaptive C2C interface communicating with each other through the interposer; 14. The system of claim 13, further comprising: a second chiplet connected to the interposer and comprising a third adapted C2C interface, wherein the anchor comprises a fourth adapted C2C interface configured to communicate with the third adapted C2C interface in the second chiplet through the interposer.

16. 16. The system of claim 7, 13 or 15, wherein the plurality of different C2C protocols are streaming C2C protocols.

Images