Patent Description:
As computer systems become more closely integrated, chip-to-chip (C2C) interfaces are more widely used. One such computing system is an anchor chip (e.g., a processor, application specific integrated circuit (ASIC), field programmable gate array (FPGA), or system on a chip (SOC) that uses C2C interfaces to communicate with one or more chiplets (e.g., high speed I/O or high bandwidth memory (HBM)). In order to achieve the chiplet based architecture, the C2C interface must be defined clearly. C2C interfaces are constrained by the area of the beachfront (e.g., the sides of the anchor chip) which limits the number of signals and wires that can pass through the interface. The required bandwidth is therefore achieved by running the interface at a high data rate.

However, the data protocol used by the application circuitry executing in chips may have a different word size than the size of the data words (DW) supported by the C2C interface. If the data protocol has a word size greater than the DW used by the C2C interface, than the chip cannot perform a one-to-one mapping between the protocol word and the DW. Instead, a single protocol word may be subdivided and sent across the C2C interface as multiple DWs. However, the protocol word may be only slightly larger than the DW, which means much of the bandwidth of the C2C is wasted. Another approach is to restrict the functionality of the bus-interface so that less data must be sent across the C2C, but reducing functionality might not be an option.

<CIT> describes methods, apparatus, and systems for implementing hierarchical and lossless packet preemption and interleaving to reduce latency jitter in flow-controller packet-based networks.

<CIT> describes a method for comprising message headers.

<CIT> describes a flit-based packetization approach used for transmitting information between electronic components.

So that the manner in which the above recited features can be understood in detail, a more particular description, briefly summarized above, may be had by reference to example implementations, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical example implementations and are therefore not to be considered limiting of its scope.

Various features are described hereinafter with reference to the figures. It should be noted that the figures may or may not be drawn to scale and that the elements of similar structures or functions are represented by like reference numerals throughout the figures. It should be noted that the figures are only intended to facilitate the description of the features. They are not intended as an exhaustive description of the features or as a limitation on the scope of the claims. In addition, an illustrated example need not have all the aspects or advantages shown. An aspect or an advantage described in conjunction with a particular example is not necessarily limited to that example and can be practiced in any other examples even if not so illustrated, or if not so explicitly described.

Embodiments herein describe on-demand packetization where data that is too large to be converted directly into DWs for a C2C interface are packetized instead. For example, because of limited wires, the C2C may be able to support a DW of only <NUM> bits, but the protocol (e.g., a data streaming protocol) may generate words that are <NUM> bits. The protocol words could be mapped to two DWs when transmitted on the C2C interface, but that would mean <NUM> bits of the C2C interface are used to transmit only <NUM> bits, resulting in a <NUM>% utilization of the bandwidth of the C2C interface. Instead, when identifying a protocol word that is larger than the DW of the C2C interface, a protocol layer can perform packetization where a plurality of protocol words are packetized and sent as a transfer. In one embodiment, the protocol layer removes some or all of the control data or signals in the protocol words (e.g., strobe signals, redundancy bits, error correction bits, flags, etc.) so that the protocol words no longer exceed the size of the DW. These shortened protocol words can then be mapped to DWs and transmitted as separate packets on the C2C. The protocol layer can then collect the portion of the control data that was removed from the protocol words and transmit this data as a separate packet on the C2C interface. While this may introduce some latency (since the receiving chip must wait for the control bits to be received before it can reconstruct the protocols words), it reduces the amount of bandwidth that is wasted in the C2C interface.

In another embodiment, instead of packetizing large protocol words, the protocol layer can encode the control data to reduce the size of the protocol words so they are equal to, or smaller than, the size of the DWs. For example, the control data may have a series of consecutive ones or zeros. Instead of storing each one or zero, the protocol layer can just encode the protocol word to indicate where the series begins or ends. However, if the protocol layer is unable to encode the protocol word so that it is smaller than the DW, then packetization can be used.

<FIG> is a block diagram of a communication system <NUM> with packetizers <NUM> to perform on-demand packetization for a C2C interface <NUM>, according to an example. As shown, the system <NUM> includes integrated circuits (ICs or chips) 105A and 105B. The communication system <NUM> can be an anchor-chiplet system, or any other system where two ICs communicate directly using a C2C interface. The ICs <NUM> can be ASICs, FPGAs, SoCs, CPUs, memories, etc. One IC <NUM> can be a primary IC while the other is a secondary IC, or the ICs <NUM> may be peers. In one embodiment, the ICs <NUM> may be disposed side-by-side on the same substrate, or they may be arranged in a stacked formation.

In this example, each IC <NUM> includes similar components: application circuitry <NUM>, a protocol layer <NUM>, a link layer <NUM>, and a physical (PHY) layer <NUM>. The application circuitry <NUM> represents any circuitry that performs a user function. The circuitry <NUM> can include non-programmable (hardened) circuitry, such as a processor core, data processing engine, graphics processing unit, and the like. Or the circuitry <NUM> can include programmable circuitry, such as configurable logic blocks (CLBs) or other types of programmable logic that can be customized by a user on the fly. In any case, the application circuitry <NUM> generates data that is transferred to the other IC <NUM> using the C2C interface <NUM>.

The application circuitry <NUM> uses a specific protocol to transmit data to other hardware elements in the IC <NUM> - e.g., the protocol layer <NUM>. The protocol is often different than the protocol used to transmit data on the C2C interface <NUM>. When transmitting data received from the application circuitry <NUM> on the C2C interface <NUM>, the protocol layer <NUM> performs a conversion to map a protocol word <NUM> that is compatible with the protocol used by the application circuitry <NUM> to a DW <NUM> that is compatible with the C2C interface <NUM>. The embodiments herein are not limited to any specific type of protocol, but rather can be applied to any IC where internal circuitry uses a communication protocol that is different from, or not compatible with, the C2C interface <NUM>. For example, the application circuitry <NUM> may use a data protocol such as Advanced eXtensible Interface (AXI), AXI streaming, Advanced Microcontroller Bus Architecture (AMBA-CXS), or peripheral component interconnect express (PCIe).

The protocol layers <NUM> include packetizers <NUM> for converting protocol words <NUM> to DW <NUM> and DW <NUM> to protocols words <NUM>. Although discussed in more detail below, in general the packetizers <NUM> (e.g., circuitry in the protocol layer <NUM>) remove some or all of the control data of the protocol words <NUM> so the resulting shortened protocol words <NUM> can be mapped one-to-one to DWs <NUM>. The removed control data can then be sent in a separate packet (e.g., another DW <NUM>). The packetizer <NUM> in the receiving IC <NUM> can then reconstruct the protocol words <NUM> from the packets (e.g., the DWs <NUM>) and transmit the protocol words <NUM> to the application circuitry. In this manner, the bandwidth of the C2C interface <NUM> may be more efficiently used relative to mapping one protocol word <NUM> to two or more DWs <NUM>.

The ICs <NUM> also include link layers <NUM> and PHY layers <NUM> for communicating along the C2C interface <NUM>. As mentioned above, the C2C interface <NUM> may have limited real estate to form wire connections between the ICs <NUM>. As a result, the size (e.g., number of bits) in the DW <NUM> may be less than the size of the protocol word <NUM>. But packetization can be performed in order to reduce the size of the protocol words <NUM> in an efficient way to maximize the bandwidth of the C2C interface.

<FIG> is a flowchart of a method <NUM> for performing on-demand packetization, according to an example. At block <NUM>, the packetizer in the protocol layer determines whether a protocol word received from the application circuitry exceeds the size of the DWs that are used to transmit data across the C2C interface. In this embodiment, the protocol words sometimes are larger than the DWs, but other times, are not. For example, some protocol words may have more data, or more control bits, than other protocol words. In another example, the application circuitry may use two different protocols to transmit data to the protocol layer, where one protocol (e.g., a streaming protocol) has protocol words that exceed the size of the DW but the other protocol (e.g., a memory mapped protocol) does not.

If the protocol word does not exceed the size of the DW, at block <NUM>, the packetizer performs a one-to-one mapping of the protocol word to a DW. That is, all the bits in the protocol word can be mapped to a corresponding bit in the DW. As a result, the protocol word can be transmitted in a single DW across the C2C interface.

However, if the protocol word exceeds the size of the DW, at block <NUM> the packetizer packetizes a plurality of protocol words. That is, the packetizer shortens the protocol words by removing all or a portion of the control data/bits in the words so that shortened protocol words can be mapped to corresponding DWs and transmitted on the C2C interface.

This packetization can be expressed in two blocks, where at block <NUM>, the packetizer maps data portions of the protocol words into separate DW packets. For example, the packetizer can remove all of the control bits from the protocol words so that these words now contain only the data bits (e.g., the user or application data) and are equal to, or smaller than, the DWs. As a result, these protocol words can now be mapped one-to-one with DWs.

In another example, the packetizer can remove only a portion of the control bits (e.g., strobe signals) but leave other types of control bits (e.g., error redundancy bits) so that the protocol words contain the remaining portion of the control bits as well as the data bits or user data. Again, this assumes that removing the portion of the control bits shrinks the protocol words sufficiently so they are equal to, or smaller than the DWs. Whether all or only a portion of the control data/bits are removed, the shortened protocol words can then be mapped to DWs and sent as respective packets.

At block <NUM>, the packetizer generates a DW packet containing the control data removed from each of the plurality of protocol words at block <NUM>. That is, the packetizer can collect the control data/bits removed from all the protocol words at block <NUM> and then transmit this control data in its own packet (e.g., DW) across the C2C interface. Blocks <NUM> and <NUM> are illustrated in <FIG>.

<FIG> illustrates packetizing data transmitted across a C2C interface, according to an example. In this example, a transmitter (e.g., one of the ICs <NUM> in <FIG>) wants to transmit eight protocol words <NUM> to a receiver (e.g., the other one of the ICs <NUM> in <FIG>). Each of the protocol words <NUM> includes control data and user data. It assumed that the total size of each protocol word <NUM> (the control data plus the user data) exceeds the size of the DW supported by the C2C interface.

To reduce the size of the protocol words <NUM> so they can be mapped to DWs, the packetizer removes the control data from each of the protocol words <NUM>. As shown in bottom left of <FIG>, the packetizer then sends the user data (e.g., the data portion) of the protocol words <NUM> as separate DWs (i.e., DWs 150B-150I). The packetizer also collects the control data removed from the protocol words <NUM> and transmits it as a separate packet (i.e., DW 150A). In this manner, the eight protocol words <NUM> are packetized and transmitted as nine DWs 150A-I on the C2C interface.

While <FIG> illustrates removing all of the control data, as mentioned above, the packetizer may only have to remove some of the control data in order to sufficiently reduce the size of the protocol words <NUM> to perform a one-to-one mapping with the DWs. Further, the number of protocol words <NUM> that are packetized as a group (where their control data is collected) can be a user set attribute. <FIG> illustrates packetizing eight protocol words <NUM>, but in other embodiments, <NUM> or <NUM> protocol words <NUM> may be collected and packetized. For instance, the packetizer may receive four protocol words, remove some or all of the control data from those words, and transmit five (or six) DWs on the C2C interface where one of those five DWs (or two of the six DWs) includes the control data.

The right side of <FIG> illustrates the receiver receiving the nine DWs 150A-I at the protocol layer. To convert the DWs <NUM> back into the same protocol words <NUM> generated by the transmitter, the packetizer has to receive the DW 150A containing the control data. Once this packet is received, the packetizer can reconstruct the protocol words <NUM> by combining the control data in the DW 150A with the corresponding user data in the DWs 150B-I.

Performing packetization can result in improved bandwidth utilization relative to, for example, mapping each of the protocol words to two DWs. In that case, the C2C interface would have to transmit <NUM> DWs for the eight protocol words <NUM>. While packetization can inject some additional latency (since the packetizer has to wait for the DW 150A containing the control data in order to convert the DWs 150BI back into the protocol words <NUM>), the C2C interface only has to transmit nine DWs, which saves bandwidth that can be used to transmit other protocol words (e.g., another batch of eight protocol words).

<FIG> is a flowchart of a method <NUM> for encoding control signals to avoid packetization, according to an example. While packetization can improve performance relative to mapping protocol words to multiple DWs, it does add latency. Thus, it may be advantageous to encode the control data in a protocol word so the size of the protocol word is equal to, or less than, the size of the DW since doing so would permit a one-to-one mapping and avoid the latency associated with packetization. The method <NUM> illustrates a packetizer that can encode the control data.

At block <NUM>, the packetizer determines whether the protocol word exceeds the size of the DW. This can be similar to block <NUM> in the method <NUM> where on some occasions the protocol word may be larger than the DW, but other times the protocol word may be equal to or smaller than the DW. If the protocol word is equal to or smaller than the DW, the method <NUM> proceeds to block <NUM> of method <NUM> where the protocol word is transmitted using a one-to-one mapping. Otherwise, the method <NUM> proceeds to block <NUM> where the packetizer determines whether there is a hole in the control signal. Stated differently, the packetizer determines whether the control data in the protocol word can be encoded into a smaller size. In general, if the control data includes a hole - e.g., a series of ones bordered on both sides by zeros, or a series of zeroes bordered on both sides by ones, or a series of ones ends in a non-last word of transfer of a plurality of protocol words, or a series of ones starts in the last word of a transfer of a plurality of protocol words - this means the control data cannot be encoded. In that case, the method <NUM> proceeds to block <NUM> of the method <NUM> where packetization is performed like shown in <FIG>.

<FIG> illustrates control data that can and cannot be encoded, according to an example. That is, <FIG> illustrates control data in a transfer of protocol words that have holes, and control data that does not have holes. The control data in <FIG> is strobe signals in AXI-Streaming, but the embodiments herein can be applied to any protocol that has control data with a series of ones or zeros (e.g., an identifiable pattern). In this example, the portion of the control data with hatching indicate "ones" (valid bits) while the empty portion of the control data indicate "zeros" (invalid bits). Further, the embodiments can also be applied to any protocol that has control data with other types of identifiable patterns. For example, the control data may have one or more patterns of ones and zeros (e.g., <NUM>) which could be encoded using fewer bits. Thus, the embodiments are not limited to control data containing a series of ones or zeros.

The top four examples in <FIG> illustrate control data for a transfer of protocol words that do not have holes. In these examples, the control data can be encoded or compressed. For example, instead of transmitting all the bits in the control data, the DW can just indicate the location of the first valid byte location in the non-last protocol word in the transfer (i.e., when TLAST is <NUM>), or the location of the first invalid byte in the last protocol word in the transfer (i.e., when TLAST is <NUM>). A flag bit can be used to indicate when all the bytes of data in the control data for the transfer are valid. In this manner, when there are no holes in the strobe signals, the DW only needs a few bits (e.g., <NUM> bits or less) to encode or represent all of the control data. This encoding or compression of the control data may be enough to reduce the size of the protocol word so that a one-to-one mapping can be performed between encoded protocol word and the DW. For example, if the protocol word is <NUM> bits but the DW is <NUM>, encoding the control data in the protocol word may reduce it to <NUM> bits or less so that each bit can be mapped to a corresponding bit of the DW.

The bottom six examples in <FIG> illustrate examples where there are holes in the control data, which means the control data cannot be encoded or compressed. Using AXI-streaming as an example, a transfer of protocol words has a hole if one or more of the following conditions are false: <MAT>.

Returning to the method <NUM>, assuming there are no holes in the transfer (e.g., a group of protocol words), the method <NUM> proceeds to block <NUM> where the packetizer encodes the control data such that the size of the encoded protocol word(s) does not exceed the size of the DW. Using the example in <FIG>, some bits of the DW are used to indicate the location of the first valid byte location in the non-last protocol word in the transfer, or the location of the first invalid in the last protocol word in the transfer. A flag bit can be used to indicate when all the bytes of data in the control data for the transfer are valid.

At block <NUM>, the packetizer can perform a one-to-one mapping for the encoded protocol word(s) in the transfer to respective DWs. As a result, the encoded protocol words can be transmitted on the C2C with the same efficiency as a protocol word that original did not exceed the size of the DW. Thus, encoding the protocol words avoids the latency introduced by packetization.

Encoding the protocol words can be described mathematically. Assume the protocol (e.g., bus-interface) transmits words to the protocol layer that include M data bits (e.g., user data) and N control bits. Suppose the DW has D wires that are available. The problem is stated as follows: Given that M + N > D, M < D, N < D, define a method to restrict N to K under restricted functionality such that M + K ≤ D, and define a method to packetize N when N cannot be restricted to K, so that the desired trade-off between bandwidth and latency can be achieved. When a transfer arrives such that N cannot be compressed to K, the packetizer packetizes the transfer as shown by the "YES" result of the block <NUM>. Packetization can be expressed as follows: Let R be a positive integer such that N*R ≤ D-<NUM> < N*(R+<NUM>). The packetizer accumulates R transfers, strips the N control bits and accumulates them separately in a register. Once the R transfers have been accumulated, the packetizer sends the "header" flit, which would be the R control bits, followed by the R transfers. This is illustrated in <FIG> above.

Otherwise, if N can be compressed to K, then the packetizer compresses the protocol words so that these encoded words can be mapped one-to-one with the DWs. This is illustrated by blocks <NUM> and <NUM> in the method <NUM>.

Further, the method <NUM> can be modified to be used with a protocol that always generates protocol words that exceed the size of the DW. In that case, the logic of block <NUM> can be omitted since the protocol words are always larger than DW. However, the packetization is still "on-demand" since the packetizer can determine, on the fly, whether the protocol words can be encoded or compressed (e.g., when the control data does not have a hole), and if so, transmit the encoded protocol words without performing packetization. If, however, the protocol words cannot be compressed or encoded such that their size is reduced to be equal to, or less than, the size of the DW, then packetization is performed.

<FIG> is a flowchart of a method <NUM> for decoding control signals and performing reverse packetization on data words received at a chip-to-chip interface, according to an example. While the method <NUM> describes the logic in a packetizer in a transmitter IC, the method <NUM> describes the logic in a packetizer in a receiver IC.

At block <NUM>, the packetizer receives a DW from the PHY and link layers after being transmitted across the C2C interface. At block <NUM>, the packetizer determines whether the DW was sent normally (i.e., without being encoded or packetized), using control data that was encoded, or by packetization. For example, the first DW in a transfer may have one or more bits used to indicate how the transmitting packetizer processed the protocol words (e.g., a direct one-to-one mapping with a DW, performed control data encoding, or packetization).

If the DW was sent normally (i.e., the original protocol word did not exceed the size of the DW), the method <NUM> proceeds to block <NUM> where the packetizer converts the DW back to the protocol word.

However, if the transmitting packetizer encoded the control data, the method <NUM> proceeds to block <NUM> where the receiving packetizer decodes the control data in the DW. That is, the packetizer can evaluate the encoded data and determine the location of the first valid byte location in the non-last protocol word in the transfer, or the location of the first invalid in the last protocol word in the transfer. Or the packetizer may evaluate a flag bit to determine when all the bytes of data in the control data for the transfer are valid.

At block <NUM>, once decoded, the packetizer can use this information to convert the decoded DW into the original protocol word.

If the DW was packetized, the method <NUM> proceeds to block <NUM> where the receiving packetizer waits until receiving the entire packet transfer. For example, as shown in <FIG>, the packetizer may know that each packetization transfer includes nine DWs, and as such, when detecting a DW is the first word in a transfer, the packetizer waits until receiving all nine DWs in that transfer.

At block <NUM>, the packetizer merges the removed control data back in the protocol words. In this manner, the packetization process is reversed so that the original protocol words are reconstructed as shown by the last step of <FIG>.

In the preceding, reference is made to embodiments presented in this disclosure. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Furthermore, although embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the preceding aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s).

Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to 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 thereon.

In the context of this document, 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.

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 this disclosure.

Claim 1:
An integrated circuit (105A, 105B), comprising:
application circuitry (<NUM>);
a chip-to-chip, C2C, interface (<NUM>); and
a protocol layer (<NUM>) connected between the application circuitry (<NUM>) and the C2C interface (<NUM>), wherein the protocol layer (<NUM>) is configured to:
receive a plurality of protocol words from the application circuitry (<NUM>), to be transmitted on the C2C interface (<NUM>), that each exceeds a size of a data word, DW, supported by the C2C interface (<NUM>), and
packetize the plurality of protocol words by:
mapping subportions of the plurality of protocol words to separate DWs, wherein each of the subportions are equal to, or less than, the size of the DW, and
generating at least one DW that contains the remaining portions of the plurality of protocol words not included in the subportions.