Technical Field

[0001] Embodiments of the present disclosure generally relate to the field of device interconnects, in particular to communications between master and slave devices via a bus or other interconnect.

Background

[0002] The I3C protocol, which is maintained via the MIPI® Alliance, is suitable for a broad range of device interconnect applications that include, for example, communications between sensor and memory interfaces.

[0003] Detecting and correcting a communications integrity checksum error is a frequent scenario in both serial and parallel communications between the master and slave devices. Legacy implementations of detecting and correcting a communications integrity checksum error may involve special signaling, or a new command to repeat the transmission of previous packets. In legacy implementations, some protocols, for example Inter-Integrated Circuit (l ² C), do not have any built-in mechanism to inform either device about communication errors, and simply accept data loss. In other protocols, the receiver (master or slave) may provide an ACK or NACK indication via a dedicated bus signaling mechanism. For example, a system management bus (SMBus) has a dedicated clock pulse. In other protocols, the receiver sends an explicit message indicating the need to retransmit data, or the receiver piggybacks a retransmission request when the data is sent in the other direction. However, these legacy implementations have various disadvantages.

Brief Description Of The Drawings

[0004] Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings. [0005] FIG. 1 illustrates communication sequences between a slave and a master device, in accordance with various embodiments.

[0006] FIG. 2 illustrates examples of packet transmissions of a package from a slave to a master device, in accordance with various embodiments.

[0007] FIG. 3 shows an example process for implementing repeated in sequence packet transmission in a slave device, in accordance with various embodiments.

[0008] FIG. 4 shows an example process for implementing repeated in sequence packet reception with checksum comparison in a master device, in accordance with embodiments.

[0009] FIG. 5 is a block diagram of a system in accordance with an embodiment.

[0010] FIG. 6 is a block diagram of a system in accordance with an embodiment.

[0011] FIG. 7 illustrates an example computing device suitable for use with various components of FIGs. 1 -6, in accordance with various embodiments.

[0012] FIG. 8 depicts a computer-readable storage medium that may be used in conjunction with a computing device, in accordance with various embodiments.

Detailed Description

[0013] Embodiments described herein may be directed to apparatus, process, or techniques for packet communication between a master node and a slave node. Embodiments include efficiently retransmitting a packet after detecting a communications integrity checksum error. In embodiments, a slave node will repeatedly transmit a package in a sequence of packets, that includes a checksum, to a master node until the master node indicates that the slave node should stop transmitting packets. In embodiments, the master node will receive the sequence of packets of the package, and determine a checksum of the received packets. During this time the master node will continue to receive packets from the slave node until a valid package is identified by the master node. If the determined checksum of the packets calculated by the master node does not match the checksum included in the transmission of the sequence of packets, then the master node may compare the contents of one or more received packets, respectively, to the contents of the one or more packets that were received one or more additional times and rebuild/correct the one or more incorrect packets. In embodiments, the master node will identify and correct contents of the one or more incorrect packets based on whether the content changes conform to the transmitted checksum.

[0014] Legacy implementations such as discussed in the Background have disadvantages. These legacy implementations are not always sufficient to correct checksum errors, or the implementation requires higher-layer protocols or firmware level to retransmit data, which may be less efficient than embodiments of the lower layer protocol mechanisms described herein.

[0015] Furthermore, legacy implementations may require the receiver of the data to calculate the integrity checksum in real time and be able to indicate an ACK/NACK result immediately. For example, the SMBus requires a response within practically one clock cycle. For this reason, this legacy approach is only possible in case of relatively slow communication buses. In addition, these legacy approaches may require new messages to be transmitted over a bus and handled by the sender of the data. These approaches may also require the sender to keep the copy of the data in a retransmit buffer. Finally, these legacy implementations may require a relatively complex mechanism to be defined between the sender and the receiver that may only work in situations when the communication is relatively symmetric, when communication in both directions occur on predictably periodic intervals.

[0016] In embodiments described herein, a slave node, after transmitting the sequence of packets of a package to the master node, will wrap around to the beginning of the sequence and then repeatedly retransmit the sequence of packets of the package to the master node until the master node tells the slave node to stop. It may take some time for the master node to calculate the integrity checksum, during this time the slave node will continue to transmit packets to the master node. In embodiments, the master node can stop the transmission once the master node determines that the checksum for the package is correct. If the checksum is not correct, the extra packets received may be used by the master node to identify errors in already received packets, and then recalculate and verify the checksum. In embodiments, the repeated read of the package may be adjusted to a different clock rate to improve the chance of a successful transmission.

[0017] Embodiments described herein may speed up transmission and error correction in data sent from the slave node to the master node. In addition, these embodiments provide an efficient resource use for the slave node. The slave node does not need to keep data in a separate retransmit buffer when waiting for the receiver to acknowledge successful transmission or request retransmission. Instead, the slave node wraps around to begin sending the data again from the same transmit buffer. That is, a slave node does not free or release a transmit buffer or queue holding packets of a package until the master node has informed the slave device to stop transmitting. In addition, modification of the clock speed for second or subsequent package transmissions makes it more likely for a subsequent retransmission to be successfully received by the master node.

[0018] In embodiments, checksum calculation and verification by the master node may take as much time as needed by the master node, as the slave node operates independently of the master node performance. In embodiments, when the master node continues to clock the signal (e.g., place a signal on the clock signal bus), after the last packet of the package, the slave node will continue to resend packets as long as the clock continues. With embodiments described herein, timing dependencies, retransmit buffer sizes, and the like do not need to be defined or negotiated between the master node and the slave node.

[0019] In the following description, various aspects of the illustrative implementations will be described using terms commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. However, it will be apparent to those skilled in the art that embodiments of the present disclosure may be practiced with only some of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative implementations. It will be apparent to one skilled in the art that embodiments of the present disclosure may be practiced without the specific details. In other instances, well-known features are omitted or simplified in order not to obscure the illustrative implementations.

[0020] In the following detailed description, reference is made to the accompanying drawings that form a part hereof, wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments in which the subject matter of the present disclosure may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure.

[0021] Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of embodiments is defined by the appended claims and their equivalents.

[0022] For the purposes of the present disclosure, the phrase "A and/or B" means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase "A, B, and/or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

[0023] The description may use perspective-based descriptions such as top/bottom, in/out, over/under, and the like. Such descriptions are merely used to facilitate the discussion and are not intended to restrict the application of embodiments described herein to any particular orientation.

[0024] The description may use the phrases "in an embodiment," or "in embodiments," which may each refer to one or more of the same or different embodiments. Furthermore, the terms "comprising," "including," "having," and the like, as used with respect to embodiments of the present disclosure, are synonymous.

[0025] The term "coupled with," along with its derivatives, may be used herein. "Coupled" may mean one or more of the following. "Coupled" may mean that two or more elements are in direct physical or electrical contact. However, "coupled" may also mean that two or more elements indirectly contact each other, but yet still cooperate or interact with each other, and may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other. The term "directly coupled" may mean that two or more elements are in direct contact.

[0026] As used herein, the term "module" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.

[0027] The terms "master" and "slave" as used herein are for their technical meaning. Either may also be referred to as "source" and "sink" nodes, or "transmit" and "receive" nodes, or “controller” and “target” nodes.

[0028] FIG. 1 illustrates communication sequences between a slave and a master device, in accordance with various embodiments. Communication sequences 100 show various data signals passing back and forth between a master node 104 and a slave node 102. In embodiments, the communication sequences 100 may be based on the MIPI™ Alliance Improved Inter Integrated Circuit (I3C) protocol. However, other embodiments may include I2C, SMBus, universal asynchronous receiver/transmitter (LIART), serial peripheral interface (SPI), management component transport protocol (MCTP) or other protocol that facilitates communication between devices. In embodiments, the master node 104 and the slave node 102 may represent communications between any first node and second node. In embodiments, the communication bus between the master node 104 and the slave node 102 may be a serial bus or a parallel bus.

[0029] Communication sequences 100 includes a clock bus 106 that may be driven by the master node 104. In embodiments, the clock may be implemented on a serial bus. When the master node 104 drives the clock bus 106 to a high value, that indicates to the slave node 102 that a packet should be transmitted. In embodiments, the master node 104 may send a transmit request 108 to the slave node 102 to begin to transmit the packets of the package. In response, the slave node 102 will repeatedly send N number of packets that make up a package to the master node 104. Note “repeated” need not be the sending of multiple full packages. In fact, a repeated transmission may only include one or a few packets of a package that are retransmitted. As such the term “repeated” means only that at least one previously sent portion of a package (e.g., one or a few chunks or packets) are sent more than once. Note that the continued communication of at least a portion of a package occurs as a single transaction. Stated another way, this repeated communication is not a separate transaction in response to another request; it is part of a single prolonged transaction in response to a single request.

[0030] In embodiments, a header packet, for example the first packet, may include an indication of the number of packets in the package, in this case N. In addition, the slave node 102 may calculate a checksum value based upon the contents of all of the N packets to be sent, and include that data in one or more packets as well.

[0031] At this point, the slave node 102 will continually send the N packets on a data bus 1 10 to the master node 104, until an indication is received from the master node 104. As the master node 104 receives and analyzes the packets, the master node 104 will decide when to direct the slave node 102 to stop sending packets. At this point, it may send a stop request 112 to the slave node 102, or may alter a clock signal on the clock bus 106.

[0032] In embodiments, the master node 104 may send an ACK or confirmation to the slave node 102 to confirm the checksum is correct which implies that the slave node 102 is to stop. In some cases, this stop indication may be sent on a sideband interface.

[0033] Considering the communication sequences 100 with respect to the I3C protocol, the slave node 102 would get its data clocked out by the I3C master node 104. Upon reaching the last packet, the slave node 102 would resend the same packet sequence again and again until the master node 104 stops the transmission. In embodiments, the transmission may be stopped using a stop communication 1 12, or by altering the clock signal on the clock bus 106. The master node 104 calculates the protocol-specified checksum after receiving the package. If the checksum was calculated in firmware within the master node 104, this could take extra time during which the clock would keep running, and the repeated packets would continue to be sent by the slave node 102 to the master node 104. If the master determined that the checksum was correct (or the checksum "passed"), the transmission from the slave (for this transaction) would be terminated and a subsequent read by the master node 104 for a different transaction would fetch the next package. If the checksum failed, the clocks would continue until additional copies of the packets could be tested for having the correct checksum.

[0034] In embodiments, the number of packets N is known. For example, how many bytes are expected to be transmitted from the slave node 102 to the master node 104, such as a fixed length for a variable value in a packet header. In embodiments, additional function may be placed in the master node 104 to be able to execute variations of the embodiments described above. Additional functions of the master node 104 may include determining if a byte in a repeated packet differs from the initial packet. If so, then the integrity checksum is recalculated based upon the repeated content. If that integrity checksum recalculation causes the checksum for the package to pass, then the master node 104 would use the repeated content and would indicate to (or cause) the slave node 102 to stop transmission. In a related embodiment, if several bits differ in one or more packets from their respective repeated packets, then the master node 104 may calculate the integrity checksum for each permutation of the differing bits for either the first or second transmission. If a valid checksum is found, then the master node 104 would assemble the transmitted package using the permutation of packets that resulted in the valid checksum.

[0035] Embodiments of additional functions of the master node 104 may also include identifying extra missing clock pulses on the clock 106. This may be based on cross correlating multiple instances of received packets to piece together one good packet when there are higher bit error rate conditions. In other embodiments, the master node 104 may compare repeated packets to a first pass where the packet was received to determine a true packet length, even if a length field within a packet has bit errors. In embodiments, this may be achieved with the protocol header differentiated from content.

[0036] In embodiments, the master node 104 may assume that the length of the package is a first byte of the content of a packet, and the master may read the length byte twice to confirm the correctness of the length. If an incorrect length was received in the first transmission, and the checksum still match the incorrect content, this may help detect such an error without packet loss when the misread length was longer than the packet.

[0037] In other embodiments, the master node 104 and the slave node 102 may invert or algorithmically modify packets after each pass. This may result in improved package length detection and better error handling where errors resulted from interference from neighboring signals, or where the errors are packet sequence dependent. In other embodiments, the master node 104 and the slave node 102 may insert a delimiter after each transmission of the package, for example, a specific data pattern. This known pattern may then simplify the detection of packet length or detection of a clock slip.

[0038] Considering the I3C protocol as an example, additional rules for a I3C master such as master node 104, while receiving data, may include the following. In one example, there may be separate checksums for the header and the payload. If the header integrity checksum is incorrect, the I3C master node 104 will stop driving the clock on the clock bus 106, causing an incomplete package transfer. This will indicate to the slave node 102 that it should retransmit the whole package on the next read. In another example, if the package checksum is incorrect, the master node 104 may drive the clock on the clock bus 106 as long as needed to receive correct data and compute and verify the package checksum. In another example, if package integrity checksum is correct, the I3C master node 104 will complete the transaction with a final pulse on the clock bus 106.

[0039] Further considering the I3C protocol as an example, additional rules for a I3C slave such as slave node 102, may follow these rules. In one example, if the master node 104 stops driving the clock bus 106 before the complete package is transferred, the slave node 102 retransmits the entire package on the next read transaction. In another example, if the master node 104 continues driving the clock 106 after the complete package has already been transferred on the bus 110, the slave node 102 starts retransmitting the package from the beginning.

[0040] FIG. 2 illustrates examples of packet transmissions of a package from a slave to a master device, in accordance with various embodiments. Examples 200, 220, 240, 260, 280 present various scenarios and actions that a master node 104, which may be an I3C master, may take.

[0041] Example 200 is an example scenario when the master node 104 needs additional time to calculate a CRC checksum. In this example, the master node 104 of FIG. 1 has calculated the CRC just after receiving retransmitted packet number two 214, and has determined that the CRC checksum is correct. The master node 104 then sends a stop 216 to the slave node 102.

[0042] Example 220 presents a scenario when I3C master detects CRC checksum error due to byte 5 error 224. When this happens, the master just continues to drive the clock and stops the transaction after it is able to calculate the correct checksum using re-transmitted byte 5 226.

[0043] Note: data 6, 7, 8, 9, and CRC are reused from the previous transaction so there is no need to retransmit the whole package. Note that, in embodiments, the second read of the package could be read at a different (slower) clock rate to improve the chance of success.

[0044] It should be noted that CRC checksum calculation by the master node 104 may take an arbitrary amount of time during which the transmissions 1 10 from the slave node 102 continue. Example 240 presents a scenario when I3C master needs time of 4 bytes 246 to calculate the CRC checksum. When CRC is correct, it stops the transaction after 4 more bytes have been transmitted. Note that no timing negotiation is necessary with the slave node 102 and the timing could even vary from packet to packet.

[0045] Example 260 shows that when the transfer is interrupted early, e.g. before the whole package transmission is complete, the whole package may be transmitted anyway. As shown, package #1 262 was stopped prior to the slave node 102 transmitting all of its packets. This causes package #1 264 to be resent.

[0046] Example 280 shows that if the whole package has been transmitted and thereafter a stop is received, the next transmission is for a subsequent package. For example, after transmitting the 9-byte long package #1 282, a subsequent package #2 284 should be transmitted.

[0047] FIG. 3 shows an example process for implementing repeated in sequence packet transmission in a slave device, in accordance with various embodiments. Process 300 may be performed by a slave node 102 that is in communication with the master node 104 as shown and described in FIG. 1 . Process 300 may be performed using the techniques described with respect to FIGs. 1 and 2. Process 300 may be implemented by the slave operation module 718 of computing device 700 of FIG. 7. Although this embodiment is shown from the point of view of a slave device, any device can perform process 300 to send packages in accordance with an embodiment. That is, any device that transmits information can perform the process, not just a slave node that responds to a master node transmit request.

[0048] At block 302, the process may include receiving, by the slave node from a master node, a request to transmit the package. In embodiments, this may be a request from the master node 104 using a transmit request to send message 108 to the slave node 102. In other embodiments, the master node 104 may drive a clock 106 high to the slave node 102 to indicate a transmission should begin. [0049] At block 304, the process may include identifying, by the slave node, a sequence of packets of the package. In embodiments, the slave node 102 divides a package into a series of packets. For instance, example 200 of FIG. 2 shows a package that is divided into 10 packets, zero through nine and a CRC checksum. In addition, various packets may be used to hold other information, for example header information, or an indication of the length, in packets, of the package. Note that in some implementations terminology may differ, for example the packets may be referred to as bytes, with the sequence of bytes referred to as a packet. Of course, other sizes of sequence chunks such as nibble, word, doubleword or other block sizes, may be used in other implementations.

[0050] At block 306, the process may include identifying, by the slave node, a checksum value based upon the contents of the packets. In embodiments, as noted above, the slave node 102 of FIG. 1 may calculate a checksum for the package based upon the contents of the individual packets.

[0051] At block 308, the process may include repeatedly transmitting, by the slave node, the sequence of the packets to the master node until a request is received from the master node to stop transmission. In embodiments, the slave node 102 of FIG. 1 repeatedly sends the sequence of packets from block 304 to the master node 104. In embodiments, each packet may be sent on a clock pulse of the clock 106. This repeated transmission will continue until a notification from the master node 104 is received by the slave node 102. In embodiments, this may be a stop message 112, or may be stopping the clock pulse 106. Note that this continued or repeated transmission may be of only one or a small number of packets or other chunks, until a stop is indicated.

[0052] FIG. 4 shows an example process for implementing repeated in sequence packet reception with checksum comparison in a master device, in accordance with embodiments. Process 400 may be performed by the master node 104 as it communicates with the slave node 102 as shown and described with respect to FIG. 1 . Process 400 may be implemented by the master operation module 719 of computing device 700 of FIG. 7. Although this embodiment is shown from the point of view of a master device, any device can perform process 400 to receive and process packages in accordance with an embodiment. That is, any device that receives packages with retransmitted information can perform the process, not just a master node that receives a repeated transmissions from a slave node.

[0053] At block 402, the process may include transmitting, by the master node, a request to the slave node to transmit a package. In embodiments, this may be performed by the master node 104 sending a request to send 108 to the slave node 102.

[0054] At block 404, the process may include receiving, from the slave node, a sequence of packets of the package. As described above, the slave node 102 will repeatedly send packets 110 that make up the package to the master node 104, until the master node 104 instructs to stop. In many cases, only a single full package may be sent, and the repeated sequence may be only a portion of the original package.

[0055] At block 406, the process may determine whether the package has been received. In embodiments, the master node 104 may determine whether the package, that includes all of the individual packets, has been received. In embodiments, this may be determined based on a comparison of a number of packets received versus a packet count sent as part of one of the packets. In other embodiments, this may be determined based upon receiving a packet, or a byte sequence, that identifies an end packet of the package. Upon the determination that the package has been received, the actions of the following blocks may be performed.

[0056] At block 408, the process may include calculating, by the master node, a checksum of the received packets.

[0057] At block 410, the process may include comparing, by the master node, the calculated checksum with a received checksum from the sequence of packets.

[0058] At block 412, the process may include, upon the calculated checksum and the received checksum being not equal, modifying one or more of the received packets based on a comparison of content of the one or more received packets, respectively, with one or more corresponding subsequent received packets of the repeated sequence of packets. Note that this “modifying” may be by replacing a given packet when the contents of this repeated packet and its corresponding original packet differ, based on a comparison of corresponding packets, as determined by comparison circuitry present in the master node.

[0059] Although not shown in FIG. 4, understand that if at block 410 the comparison of the calculated and received checksum match, a stop indication may be sent to the slave node, to cause it to stop retransmitting.

[0060] Also understand that in the case of mismatched checksums, the master node may cause a reduction in clock rate. For example in an I3C implementation, for a next repeated package transmission, clock rate may be reduced from 12.5 megahertz (MHz) to 12.0 MHz, and so on, to better ensure accurate transmission. Also the master node may be configured to perform parallel and/or interim checksum operations to quickly identify when a fully accurate package is received.

[0061] Referring now to FIG. 5, shown is a block diagram of a system in accordance with an embodiment. More specifically, system 500 shown in FIG. 5 represents at least a portion of any one of a variety of different types of computing devices. In different embodiments, such computing devices can range from relatively small low power devices such as a smartphone, tablet computer, wearable device or so forth, to larger devices such as laptop or desktop computers, server computers, automotive infotainment devices and so forth. In any case, system 500 includes a bus 515. In embodiments herein, bus 515 may be implemented as an I3C bus in accordance with one or more I3C specifications. However, understand that in other embodiments, bus 515 may be implemented as any type of multi-drop interconnect.

[0062] As illustrated, a primary or main master device 520 couples to bus 515. In various embodiments, master device 520 may be implemented as a host controller that includes hardware logic to act as a bus master for bus 515. Master device 520 may include a controller (not shown in the high level view of FIG. 5) to control data (SDA) and clock (SOL). In some cases, master device 520 may be a relatively simple host controller for a low complexity bus or other multi-drop bus, such as in accordance with an l ² C or I3C Specification. Other multi-drop interfaces such as SPI and/or Microwire also may be present in a particular embodiment.

[0063] In different implementations, master device 520 may be an interface circuit of a multicore processor or other SoC, application processor or so forth. In other cases, master device 520 may be a standalone host controller (such as a given integrated circuit (IC)) or main master device for bus 515. And of course other implementations are possible. In other cases, master device 520 may be implemented as hardware, software, and/or firmware or combinations thereof, such as dedicated hardware logic, e.g., a programmable logic, to perform bus master activities for bus 515.

[0064] Note that bus 515 is implemented as a two-wire bus in which a single serial line forms a data interconnect and another single serial line forms a clock interconnect. As such, data communications can occur, e.g., in bidirectional manner and clock communication can occur in a single direction. Master device 520 may be a relatively compute complex device (as compared to other devices on bus 515) that consumes higher power than other devices coupled to bus 515.

[0065] As shown in FIG. 5, multiple secondary master devices 530i - 530N are present. In various embodiments, secondary master devices 530 (generically) may be implemented as dedicated master or bridge devices such as standalone IC’s coupled to bus 515. In other cases, these devices may be independent logic functionality of a SoC or other processor (and in some cases may be implemented in the same IC as master device 520 known as a secondary master). One or more such secondary master devices 530 may be controlled to act as bus master for bus 515 while main master device 520 is in a low power state, to enable bus operations to continue to proceed while in this low power state.

[0066] As further illustrated in FIG. 5, a plurality of slave devices 540i - 540N also couple to bus 515. In different embodiments, slave devices 540 (generically) may take many different forms. For purposes of example, slave devices 540 may include one or more of an SoC, network interface circuit (NIC), solid state drive (SSD) or other memory such as a dual inline memory module (DIMM), CPU, or other devices such as sensors, peer-to-peer devices, debug devices or so forth. Understand while shown at this high level in the embodiment of FIG. 5, many variations and alternatives are possible.

[0067] Referring now FIG. 6, shown is a block diagram of a system in accordance with an embodiment. As shown in the high level view of FIG. 6, system 600 may take the form any type of computing system that includes at least one slave device 610 and at least one master device 650, which are coupled via an I3C bus (implemented with separate clock (SCL) and data (SDA) lines in FIG. 6). More specifically in the high level view of FIG. 6, various details within these devices for handling repeated in sequence transmission of a single message or transaction is shown.

[0068] With regard to slave device 610, a processing circuit 612, which may be a CPU, GPU, microcontroller, one or more processor cores or other processing or memory circuits, may generate data to be read by master device 650. For a given data unit, the data may be provided for temporary storage in a transmit queue 618, where it may be temporarily stored before it is sent via a driver 638 to master device 650 via the data line.

[0069] As further shown, incoming information from master device 650 may be received via the data line in a receiver 632 that in turn couples via a receive queue 616 to processing circuit 612. As further illustrated, an incoming clock signal may be received via the clock line in a receiver 635 that in turn couples to a clock circuit 628. Understand that clock circuit 628 may forward or internally generate one or more clock signals based on this incoming clock signal for provision to various components of slave device 610.

[0070] As further illustrated in FIG. 6, slave device 610 also includes a link control circuit 620. In addition to acting as an interface for the I3C bus, link control circuit 620 may include a transmit controller 622 that may control transmission of a message in transmit queue 618. To this end, transmit controller 622 may cause at least a portion of the message (e.g., one or more packets) to be retransmitted from transmit queue 618 until a stop indication is received from master device 650. When this stop indication is received (e.g., via termination of the driving of a clock signal), transmit controller 622 may free transmit queue 618 (or at least this message). To enable the repeated transmission described herein, transmit controller 622 may access configuration information in a configuration register 625. Such information may include an enable indicator for this retransmission mode, which when set, indicates that prolonged transactions are to be sent (namely the repeated transmission of one or more portions of a message, until a stop indication is received). In embodiments, link control circuit 620 may generate one or more checksum values to be communicated with a package.

[0071] With reference now to master device 650, a processing circuit 652 is present, which may send commands and other information to slave device 610 via a driver 656. In turn, processing circuit 652 may receive incoming information from slave device 610 via a receiver 658. As further illustrated, master device 650 also includes a link control circuit 670.

[0072] In embodiments, link control circuit 670 may perform various operations, including checking for errors in incoming transactions, and stopping a retransmission when no errors are present, as described herein. To this end, link control circuit 670 includes a comparator circuit 672, which may compare original and retransmitted corresponding packets or other portions of a message to identify when these portions differ. When so, the retransmitted portion can be provided to one or more checksum circuits 674o- _n , to be used in calculating new checksums to verify when a package is correctly received, as described herein. Comparator circuit 672 also may be configured to compare a received checksum to a calculated checksum, to determine whether a package was correctly received. In other implementations, a calculation circuit may be configured to perform both the checksum and comparison operations. [0073] With further reference to FIG. 6, master device 650 also includes a clock generator 660 which may generate the clock signal that is sent via a driver 665 to slave device 610. In embodiments, link control circuit 670 may further include a clock controller 675, which may control clock generator 660 to reduce the frequency of the clock signal during retransmitted portions of a package, as described herein. Understand while shown at this high level in the embodiment of FIG. 6, many variations and alternatives are possible.

[0074] FIG. 7 illustrates an example computing device 700 suitable for having elements that use with various components of FIGs. 1 -6, in accordance with various embodiments. The computing device 700 may have elements arranged to implement a master node 104 or a slave node 102 of FIG. 1 . As shown, computing device 700 may include one or more processors or processor cores 702 and system memory 704. For the purpose of this application, including the claims, the terms "processor" and "processor cores" may be considered synonymous, unless the context clearly requires otherwise. The processor 702 may include any type of processors, a microprocessor, and the like. The processor 702 may be implemented as an integrated circuit having multi-cores, e.g., a multi-core microprocessor.

[0075] The computing device 700 may include mass storage devices 706 (such as diskette, hard drive, volatile memory (e.g., dynamic random-access memory (DRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), and so forth). In general, system memory 704 and/or mass storage devices 706 may be temporal and/or persistent storage of any type, including, but not limited to, volatile and non-volatile memory, optical, magnetic, and/or solid state mass storage, and so forth. Volatile memory may include, but is not limited to, static and/or dynamic random access memory. Non-volatile memory may include, but is not limited to, electrically erasable programmable read-only memory, phase change memory, resistive memory, and so forth.

[0076] The computing device 700 may further include I/O devices 708 (such as a display (e.g., a touchscreen display)), keyboard, cursor control, remote control, gaming controller, image capture device, a camera, one or more sensors, and so forth) and communication interfaces 710 (such as network interface cards, serial buses, modems, infrared receivers, radio receivers (e.g., Bluetooth), and so forth).

[0077] The communication interfaces 710 may include communication chips (not shown) that may be configured to operate the device 700 in accordance with a Global System for Mobile Communication (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Evolved HSPA (E- HSPA), or Long-Term Evolution (LTE) network. The communication chips may also be configured to operate in accordance with Enhanced Data for GSM Evolution (EDGE), GSM EDGE Radio Access Network (GERAN), Universal Terrestrial Radio Access Network (UTRAN), or Evolved UTRAN (E-UTRAN). The communication chips may be configured to operate in accordance with Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Digital Enhanced Cordless Telecommunications (DECT), Evolution-Data Optimized (EV-DO), derivatives thereof, as well as any other wireless protocols that are designated as 3G, 4G, 5G, and beyond.

[0078] The above-described computing device 700 elements may be coupled to each other via system bus 712. System bus 712 represents various buses including e.g., I3C, where one or more of processor 702, memory 704, mass storage 706, communication interfaces 710 and I/O device 708 could be master or slave devices communicating with each other over the system bus 712.

[0079] Thus, these devices may respectively have the slave operation module 718 and/or master operation module 719 incorporated therein. In embodiments, slave operation module 718 and/or master operation module 719 may be implemented in hardware or in firmware. In particular, they may be within systems incorporated with the teachings of the present disclosure to enable repeated in sequence packet transmission, as earlier described. In the case of multiple buses, they may be bridged by one or more bus bridges (not shown). [0080] Except for the teachings of the present disclosure incorporated, each of these elements may perform its conventional functions known in the art. In particular, system memory 704 and mass storage devices 706 may be employed to store a working copy and a permanent copy of the programming instructions for the operation of various components of computing device 700, including but not limited to an operating system of computing device 700, one or more applications, and/or system software/firmware in support of practice of the present disclosure, collectively referred to as computing logic 722. Computing logic 722 may be implemented by assembler instructions supported by processor(s) 702 or high-level languages that may be compiled into such instructions.

[0081] The permanent copy of the programming instructions may be placed into mass storage devices 706 in the factory, or in the field through, for example, a distribution medium (not shown), such as a compact disc (CD), or through communication interface 710 (from a distribution server (not shown)). That is, one or more distribution media having an implementation of the agent program may be employed to distribute the agent and to program various computing devices.

[0082] The number, capability, and/or capacity of the elements 702, 704, 706, 708, 710, and 712 may vary, depending on whether computing device 700 is used as a stationary computing device, such as a set-top box or desktop computer, or a mobile computing device, such as a tablet computing device, laptop computer, game console, or smartphone. Their constitutions are otherwise known, and accordingly will not be further described.

[0083] In embodiments, at least one of processors 702 may be packaged together with computational logic 722, slave operation module 718 and/or master operation module 719 configured to practice aspects of embodiments described herein, to form a System in Package (SiP) or a System on Chip (SoC).

[0084] In various implementations, the computing device 700 may be one or more components of a data center, a laptop, a netbook, a notebook, an ultrabook, a smartphone, a tablet, a personal digital assistant (PDA), an ultra mobile PC, a mobile phone, a digital camera, or an loT user equipment. In further implementations, the computing device 700 may be any other electronic device that processes data.

[0085] FIG. 8 depicts a computer-readable storage medium that may be used in conjunction with the computing device 700, in accordance with various embodiments. Diagram 800 illustrates an example non-transitory computer- readable storage media 802 having instructions configured to practice all or selected ones of the operations associated with the processes described above. As illustrated, non-transitory computer-readable storage medium 802 may include a number of programming instructions 804 (e.g., including slave operation module 718 and/or master operation module 719). Programming instructions 804 may be configured to enable a device, e.g., a component of computing device 700, in response to execution of the programming instructions by a controller of the component, to perform one or more operations of the processes described in reference to FIGs. 1 -7. In alternate embodiments, programming instructions 804 may be disposed on multiple non-transitory computer-readable storage media 802 instead. In still other embodiments, programming instructions 804 may be encoded in transitory computer- readable signals.

[0086] The following examples pertain to further embodiments.

[0087] In one example, a method comprises: receiving, by a first device from a second device, a request to transmit a package, the package formed of a sequence of packets; generating, in the first device, a checksum value based upon the sequence of the packets; and transmitting, by the first device, the sequence of the packets to the second device, and continuing to transmit at least a portion of the sequence of the packets until an indication is received from the second device to stop transmission.

[0088] In an example, the method further comprises incorporating the checksum value into one or more of the sequence of packets. [0089] In an example, incorporating the checksum value comprises incorporating a first checksum value for a header portion of the package and incorporating a second checksum value for a payload portion of the package.

[0090] In an example, the method further comprises: determining, by the first device, a number of the packets within the package; and incorporating an indication of the determined number of packets within the package into one or more of the packets of the package.

[0091] In an example, receiving by the first device and transmitting by the first device is controlled by a clock signal received by the first device and transmitted from the second device.

[0092] In an example, the indication to stop transmission further includes stopping the clock signal.

[0093] In an example, the method further comprises continuing to transmit at least the portion of the sequence of packets at a second clock rate, the second clock rate slower than a first clock rate at which the sequence of packets is transmitted.

[0094] In an example, the method further comprises freeing a transmit buffer of the first device in response to the indication to stop the transmission.

[0095] In an example, transmitting the sequence of packets and continuing to transmit at least the portion of the sequence of packets comprises a single transaction.

[0096] In another example, a computer readable medium including instructions is to perform the method of any of the above examples.

[0097] In a further example, a computer readable medium including data is to be used by at least one machine to fabricate at least one integrated circuit to perform the method of any one of the above examples.

[0098] In a still further example, an apparatus comprises means for performing the method of any one of the above examples. [0099] In another example, an apparatus comprises: a receiver to receive, from a first device, a transmission of a package formed of a sequence of packets; and at least one calculation circuit to calculate a checksum of the package and compare the calculated checksum with a received checksum of the package. In response to the calculated checksum and the received checksum being not equal, the apparatus is to modify one or more of the received packets based on a comparison the one or more received packets, respectively, with one or more corresponding subsequent received packets of a retransmission of at least a portion of the sequence of packets of the package.

[0100] In an example, the apparatus is to modify the one or more of the received packets comprising replacement of a first packet of the sequence of packets with a retransmitted first packet of the sequence of packets, and cause the first device to continue to retransmit at least the portion of the sequence of packets.

[0101] In an example, in response to the calculated checksum and the received checksum being equal, the apparatus is to transmit an indication to stop the retransmission of the package to the first device.

[0102] In an example, the at least one calculation circuit is to calculate a plurality of checksums in parallel, each of the plurality of checksums for a different combination of received ones of the sequence of packets, including one or more retransmitted packets.

[0103] In an example, the apparatus further comprises a clock generator to send a clock signal to the first device, where in response to the calculated checksum and the received checksum being not equal, the apparatus is to cause the clock generator to send the clock signal at a lower clock rate.

[0104] In an example, the apparatus is to: calculate a header checksum for a header portion of the package and compare the header checksum to a received header checksum; and cause the first device to stop transmitting the sequence of packets if the header checksum is not equal to the received header checksum.

[0105] In another example, a system comprises a first device to couple to an interconnect, the first device comprising: a first driver to drive first information onto a first line of the interconnect; a first receiver to receive incoming information via the first line; and another driver to drive a clock signal onto a second line of the interconnect. The first device is to: receive a message from the second device via the first line; and calculate a checksum for the message and compare the checksum to a received checksum for the message and cause the second device to continue retransmission of one or more portions of the message until it is determined that the checksum and the received checksum match.

[0106] The second device coupled to the first device via the interconnect, the second device comprises: a second receiver; a second driver; and a control circuit. The control circuit is to: determine a sender side checksum for the message and include the sender side checksum in the message as the received checksum; and send, via the second driver, the message and continue to send one or more portions of the message to the first device until an indication to stop transmission is received.

[0107] In an example, the second device is to send the message and continue to send the one or more portions of the message as a single prolonged transaction.

[0108] In an example, the one or more portions of the message comprise bytesized chunks.

[0109] In an example, the indication to stop transmission comprises a de-activation of the clock signal on the second line.

[01 10] In an example, the first device further comprises a clock generator to generate the clock signal, where in response to the calculated checksum and the received checksum being not equal, the clock generator is to generate the clock signal at a lower clock rate, and the another driver is to drive the clock signal onto the second line of the interconnect at the lower clock rate.

[01 11] In another example, an apparatus comprises: means for receiving a request to transmit a package, the package formed of a sequence of packets; means for generating a checksum value based upon the sequence of the packets; and means for transmitting the sequence of the packets to a requester and continuing to transmit at least a portion of the sequence of the packets until an indication is received from the requester to stop transmission. [01 12] In an example, the apparatus further comprises means for incorporating the checksum value into one or more of the sequence of packets.

[01 13] In an example, the apparatus further comprises means for receiving a clock signal from the requester.

[01 14] In an example, the indication to stop transmission comprises stopping the clock signal.

[01 15] In an example, the means for transmitting is to transmit the sequence of packets at a first clock rate, and to continue to transmit at least the portion of the sequence of packets at a second clock rate, the second clock rate slower than the first clock rate.

[01 16] Understand that various combinations of the above examples are possible.

[01 17] Various embodiments may include any suitable combination of the above-described embodiments including alternative (or) embodiments of embodiments that are described in conjunctive form (and) above (e.g., the "and" may be "and/or"). Furthermore, some embodiments may include one or more articles of manufacture (e.g., non-transitory computer- readable media) having instructions, stored thereon, that when executed result in actions of any of the above-described embodiments. Moreover, some embodiments may include apparatuses or systems having any suitable means for carrying out the various operations of the above-described embodiments.

[01 18] The above description of illustrated implementations, including what is described in the Abstract, is not intended to be exhaustive or to limit the embodiments of the present disclosure to the precise forms disclosed. While specific implementations and examples are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the present disclosure, as those skilled in the relevant art will recognize.

[01 19] These modifications may be made to embodiments of the present disclosure in light of the above detailed description. The terms used in the following claims should not be construed to limit various embodiments of the present disclosure to the specific implementations disclosed in the specification and the claims. Rather, the scope is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.

[0120] Various embodiments may include any suitable combination of the above-described embodiments including alternative (or) embodiments of embodiments that are described in conjunctive form (and) above (e.g., the "and" may be "and/or"). Furthermore, some embodiments may include one or more articles of manufacture (e.g., non-transitory computer- readable media) having instructions, stored thereon, that when executed result in actions of any of the above-described embodiments. Moreover, some embodiments may include apparatuses or systems having any suitable means for carrying out the various operations of the above-described embodiments.

[0121] The above description of illustrated implementations, including what is described in the Abstract, is not intended to be exhaustive or to limit the embodiments of the present disclosure to the precise forms disclosed. While specific implementations and examples are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the present disclosure, as those skilled in the relevant art will recognize.

[0122] These modifications may be made to embodiments of the present disclosure in light of the above detailed description. The terms used in the following claims should not be construed to limit various embodiments of the present disclosure to the specific implementations disclosed in the specification and the claims. Rather, the scope is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.