CN116324729A

CN116324729A - Repeated sequential packet transmission for checksum comparison

Info

Publication number: CN116324729A
Application number: CN202180065115.7A
Authority: CN
Inventors: J·尤尔斯基; M·勒文; A·K·斯里瓦斯塔瓦; M·A·施努尔
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-10-23
Filing date: 2021-10-15
Publication date: 2023-06-23
Also published as: WO2022086798A1

Abstract

Embodiments described herein may be directed to an apparatus, process, or technique for packet communication between a master node and a slave node. In an embodiment, the slave node will repeatedly transmit packets in the sequence of packets to the master node including the checksum until the master node indicates that the slave node should stop transmitting packets. The master node will receive the packet sequence of the packet and determine the checksum of the received packet. The master node will continue to receive packets from the slave nodes until the master node identifies a valid packet. If the checksum of the packet calculated by the master node does not match the checksum contained in the packet sequence transmission, the master node may compare the content of the subsequently received packet with the content of one or more packets retransmitted to the master node, respectively. Other embodiments may be described and/or claimed.

Description

Repeated sequential packet transmission for checksum comparison

Technical Field

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

Background

Via a path of

The I3C protocol maintained by the federation is suitable for a wide range of device interconnect applications, including, for example, communications between sensors and memory interfaces.

Detecting and correcting communication integrity checksum errors is a common scenario in both serial and parallel communications between a master device and a slave device. Conventional implementations of detecting and correcting communication integrity checksum errors may involve special signaling or repeated transmission of new commands for previous packets. In conventional implementations, some protocols (e.g., inter-integrated circuit (Inter-Integrated Circuit, I) ² C) No built-in mechanism to notify any device about communication errors and simply accept data loss. In other protocols, the recipient (master or slave) may provide an ACK or NACK indication via a dedicated bus signaling mechanism. For example, the system management bus (system management bus, SMBus) has a dedicated clock pulse. In other protocols, the receiver sends an explicit message to indicate that data needs to be retransmitted, or when data is sent in the other direction, the receiver piggybacks the retransmission request. However, these conventional embodiments have various disadvantages.

Drawings

Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. For ease of description, like reference numerals denote like structural elements. The embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings.

Fig. 1 illustrates a communication sequence between a slave device and a master device in accordance with various embodiments.

Fig. 2 illustrates an example of packet transmission of a packet (package) from a slave device to a master device in accordance with various embodiments.

Fig. 3 illustrates an example process for implementing repeated sequential packet transmission (repeated in sequence packet transmission) in a slave device, in accordance with various embodiments.

Fig. 4 illustrates an example process for implementing repetition sequential packet reception in a master device using checksum comparison in accordance with an embodiment.

Fig. 5 is a block diagram of a system according to an embodiment.

Fig. 6 is a block diagram of a system according to an embodiment.

FIG. 7 illustrates an example computing device suitable for use with the various components of FIGS. 1-6 in accordance with various embodiments.

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

Embodiments described herein may be directed to an apparatus, process, or technique for packet communication between a master node and a slave node. Embodiments include efficiently retransmitting packets after detecting a communication integrity checksum error. In an embodiment, the slave node will repeatedly send packets in the sequence of packets to the master node including the checksum until the master node indicates that the slave node should stop sending packets. In an embodiment, the master node will receive a sequence of packets of the packet and determine a checksum of the received packet. During this time, the master node will continue to receive packets from the slave nodes until the master node identifies a valid packet. If the determined checksum of the packet calculated by the master node does not match the checksum contained in the transmission of the sequence of packets, the master node may compare the contents of one or more received packets with the contents of one or more received packets, respectively, one or more additional comparisons, and reconstruct/correct one or more incorrect packets. In an embodiment, the master node will identify and correct the content of one or more incorrect packets based on whether the content change matches the checksum of the transmission.

Conventional implementations (e.g., as discussed in the background section) have drawbacks. These conventional implementations are not always sufficient to correct checksum errors, or require higher layer protocols or firmware levels to retransmit the data, which may not be as efficient as the embodiments of the lower layer protocol mechanisms described herein.

Furthermore, conventional implementations may require the recipient of the data to calculate the integrity checksum in real time and be able to indicate the ACK/NACK result immediately. For example, the SMBus requires a response in almost one clock cycle. For this reason, this conventional approach is only possible if the communication bus is relatively slow. Furthermore, these traditional methods may require new messages to be transmitted over the bus and handled by the data sender. These methods may also require the sender to store a copy of the data in a retransmission buffer. Finally, when bi-directional communications occur at predictable periodic intervals, these conventional implementations may require a relatively complex mechanism to be defined between the sender and the receiver, which may only work if the communications are relatively symmetrical.

In the embodiments described herein, after transmitting the packet sequence of packets to the master node, the slave node will wrap around to the beginning of the sequence and then repeatedly retransmit the packet sequence of packets to the master node until the master node tells the slave node to stop. The master node may take some time to calculate the integrity checksum during which the slave node will continue to transmit packets to the master node. In an embodiment, once the master node determines that the checksum of the packet is correct, the master node may stop transmitting. If the checksum is incorrect, the master node may use the received additional packets to identify errors in the received packets and then recalculate and verify the checksum. In embodiments, repeated reads of packets may be adjusted to different clock rates to increase the chance of successful transmission.

Embodiments described herein may speed up the transmission and error correction of data sent from a slave node to a master node. Furthermore, these embodiments provide for efficient resource usage for slave nodes. The slave node does not need to keep the data in a separate retransmission buffer while waiting for the receiver to acknowledge that the transmission was successful or request a retransmission. Instead, the slave node wraps around to begin sending data again from the same transmit buffer. That is, the slave node does not vacate or free a transmission buffer or queue holding packets of the packet until the master node has notified the slave to stop transmitting. In addition, modifying the clock speed for the second or subsequent packet transmission makes subsequent retransmissions more likely to be successfully received by the master node.

In an embodiment, checksum calculation and verification of the master node may take the time required by the master node because the slave node operates independent of the master node performance. In an embodiment, as the master node continues to clock the signal (e.g., place the signal on the clock signal bus), the slave node will continue to retransmit the packet after the last packet of the packet as long as the clock continues. For the embodiments described herein, there is no need to define or negotiate timing dependencies, retransmission buffer sizes, etc. between the master node and the slave nodes.

In the following description, various aspects of the illustrative embodiments 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 embodiments. 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 embodiments.

In the following detailed description, reference is made to the accompanying drawings which form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustration embodiments in which the disclosed subject matter 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.

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

For the purposes of this disclosure, the phrase "a and/or B" refers to (a), (B), or (a and B). For the purposes of this disclosure, the phrase "A, B and/or C" refers to (a), (B), (C), (a and B), (a and C), (B and C), or (A, B and C).

The description may use perspective-based descriptions such as top/bottom, inside/outside, above/below, etc. Such descriptions are merely used to facilitate the discussion and are not intended to restrict the application of the embodiments described herein to any particular orientation.

The description may use the phrases "in one embodiment" or "in an embodiment," 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.

The term "coupled to … …" and derivatives thereof 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 are in indirect contact with 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 referred to as being coupled to each other. The term "directly coupled" may mean that two or more elements are in direct contact.

As used herein, the term module may refer to, be part of, or include an application specific integrated circuit (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.

The terms "master" and "slave" as used herein are for their technical meaning. May also be referred to as "source" and "sink" nodes, or "sending" and "receiving" nodes, or "controller" and "target" nodes.

Fig. 1 illustrates a communication sequence between a slave device and a master device in accordance with various embodiments. Communication sequence 100 illustrates various data signals communicated back and forth between master node 104 and slave node 102. In an embodiment, the communication sequence 100 may be based on MIPI ^TM Federation improved inter-integrated circuit (Improved Inter Integrated Circuit, I3C) protocols. However, other embodiments may include I2C, SMBus, a universal asynchronous receiver/transmitter (universal asynchronous receiver/transmitter, UART), a serial peripheral interface (serial peripheral interface, SPI), a management component transport protocol (management component transport protocol, MCTP), or other protocols that facilitate communication between devices. In an embodiment, the master node 104 and the slave node 102 may represent communication between any first node and second node. In an embodiment, the communication bus between the master node 104 and the slave node 102 may be a serial bus or a parallel bus.

The communication sequence 100 includes a clock bus 106 that may be driven by a master node 104. In an embodiment, the clock may be implemented on a serial bus. When the master node 104 drives the clock bus 106 to a high value, this indicates to the slave node 102 that the packet should be transmitted. In an embodiment, the master node 104 may send a transmission request 108 to the slave node 102 to begin transmitting packets of the packet. In response, the slave node 102 will repeatedly send N packets that make up the packet to the master node 104. Note that "repetition" does not have to be sending multiple complete packets. In practice, the retransmission may comprise only one or a few packets of the retransmitted packet. Thus, the term "duplicate" merely means that at least one previously transmitted portion of a packet (e.g., one or several blocks or packets) is transmitted more than once. Note that the persistent communication of at least a portion of the packet occurs as a single transaction. In other words, such repeated communications are not separate transactions in response to another request; which is part of a single extended transaction that responds to a single request.

In an embodiment, the header packet (e.g., the first packet) may include an indication of the number of packets in the packet, in this case N. Further, the slave node 102 may calculate a checksum value based on the contents of all N packets to be transmitted and include the data in one or more packets as well.

At this point, the slave node 102 will continuously send N packets to the master node 104 over the data bus 110 until an indication is received from the master node 104. When the master node 104 receives and analyzes the packet, the master node 104 will decide when to instruct 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 change the clock signal on the clock bus 106.

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

Considering the communication sequence 100 for the I3C protocol, the slave node 102 will obtain the (clocked out) data clocked out by the I3C master node 104. Upon reaching the last packet, the slave node 102 will retransmit the same sequence of packets again and again until the master node 104 stops transmitting. In embodiments, the stop communication 112 may be used or the transmission may be stopped by changing the clock signal on the clock bus 106. The master node 104 calculates a protocol-specified checksum after receiving the packet. If the checksum is calculated in firmware within master node 104, this may take additional time during which the clock will continue to run and duplicate packets will continue to be sent by slave node 102 to master node 104. If the master node determines that the checksum is correct (or that the checksum "passed"), the transmission from the slave node (for that transaction) will be terminated and a subsequent read by the master node 104 for a different transaction will take the next packet. If the checksum fails, the clock will continue until an additional copy of the packet can be tested for the correct checksum.

In an embodiment, the number of packets N is known. For example, how many bytes, e.g., a fixed length of variable value in the packet header, are expected to be transmitted from the slave node 102 to the master node 104. In an embodiment, additional functionality may be placed in the master node 104 to enable execution of variations of the above-described embodiments. Additional functions of the master node 104 may include determining whether bytes in the duplicate packet are different from the original packet. If so, the integrity checksum is recalculated based on the repeated content. If the integrity checksum recalculation results in the checksum of the packet passing, the master node 104 will use the repeated content and instruct (or cause) the slave node 102 to stop transmitting. In a related embodiment, if several bits in one or more packets are different from their corresponding duplicate packets, the master node 104 may calculate an integrity checksum for each permutation of the different bits of the first or second transmission. If a valid checksum is found, the master node 104 will assemble the transmitted packet using the packet arrangement that generated the valid checksum.

Embodiments of additional functionality of the master node 104 may also include identifying additional missing clock pulses on the clock 106. This may be based on cross-correlating multiple instances of the received packet to stitch together a good packet in the presence of higher bit error rate conditions. In other embodiments, the master node 104 may compare the repeated packet with the first pass of the received packet to determine the true packet length, even if the length field within the packet has a bit error. In an embodiment, this may be implemented with a different protocol header than the content.

In an embodiment, the master node 104 may assume that the length of the packet is the first byte of the packet content, and the master node may read the length byte twice to confirm the correctness of the length. If an incorrect length is received in the first transmission and the checksum still matches the incorrect content, this may help detect such errors without losing the packet if the misread length is longer than the packet.

In other embodiments, the master node 104 and the slave node 102 may invert or algorithmically modify the packet after each pass. This may lead to improved packet length detection and better error handling, wherein errors are caused by interference of neighboring signals, or wherein errors relate to packet sequences. In other embodiments, the master node 104 and the slave node 102 may insert delimiters, such as particular data patterns, after each transmission of a packet. This known pattern may then simplify the detection of packet length or the detection of clock slip.

Considering the I3C protocol as an example, additional rules for an I3C master node, such as master node 104, may include the following while receiving data. 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 cease driving the clock on the clock bus 106, resulting in incomplete packet transfer. This will indicate to the slave node 102 that it should retransmit the entire packet at the next read. In another example, if the packet checksum is incorrect, the master node 104 may drive a clock on the clock bus 106 as long as it is required to receive the correct data and calculate and verify the packet checksum. In another example, if the packet integrity checksum is correct, the I3C master node 104 will complete the transaction with the final pulse on the clock bus 106.

Considering the I3C protocol further as an example, additional rules for an I3C slave device, 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 packet is transmitted, the slave node 102 retransmits the entire packet at the next read transaction. In another example, if the master node 104 continues to drive the clock 106 after a complete packet has been transmitted on the bus 110, the slave node 102 retransmits the packet from scratch.

Fig. 2 illustrates an example of packet transmission of a packet from a slave device to a master device, in accordance with various embodiments. Examples 200, 220, 240, 260, 280 present various scenarios and actions that may be taken by a master node 104, which may be an I3C master node.

Example 200 is an example scenario when master node 104 requires additional time to calculate a CRC checksum. In this example, the master node 104 of fig. 1 calculates the CRC immediately after receiving the retransmitted packet number two 214 and determines that the CRC checksum is correct. Master node 104 then sends a stop 216 to slave node 102.

Example 220 presents a scenario when an I3C master node detects a CRC checksum error due to byte 5 error 224. When this happens, the master simply continues to drive the clock and stops the transaction after it can calculate the correct checksum using the retransmitted byte 5 226.

Note that: the

data

6, 7, 8, 9 and CRC are reused from previous transactions and thus the entire packet need not be retransmitted. Note that in an embodiment, the second read of the packet may be read at a different (slower) clock rate to increase the chance of success.

It should be noted that the CRC checksum calculation of master node 104 may take any amount of time during which transmissions 110 from slave node 102 continue. Example 240 presents a scenario when the I3C master node needs 4 bytes 246 of time to calculate the CRC checksum. When the CRC is correct, it will stop the transaction after a further 4 bytes have been transmitted. Note that timing negotiation with the slave node 102 is unnecessary, and the timing may even be different from packet to packet.

Example 260 shows that when the transmission is interrupted prematurely, for example, before the entire packet transmission is completed, the entire packet may be transmitted anyway. As shown, packet #1 262 is stopped before all of its packets are transmitted from node 102. This results in packet #1 264 being retransmitted.

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

Fig. 3 illustrates an example process for implementing repeated sequential packet transmissions in a slave device, in accordance with various embodiments. As shown and described in fig. 1, process 300 may be performed by a slave node 102 in communication with a master node 104. Process 300 may be performed using the techniques described with respect to fig. 1 and 2. The process 300 may be implemented by the slave operation module 718 of the computing device 700 of fig. 7. Although this embodiment is shown from the perspective of a device, any device may perform process 300 to send packets according to one embodiment. That is, any device transmitting information may perform this process, not just a slave node that responds to a master node transmission request.

At block 302, the process may include receiving, by a slave node, a request from a master node to transmit a packet. In an embodiment, this may be a request from the master node 104, the master node 104 using a transmission request 108 for sending a message to the slave node 102. In other embodiments, the master node 104 may drive the clock 106 high to the slave node 102 to indicate that the transmission should begin.

At block 304, the process may include identifying, by the slave node, a sequence of packets of the packet. In an embodiment, the slave node 102 divides the packet into a series of packets. For example, example 200 of fig. 2 shows one packet (which is divided into 10 packets, from zero to nine) and a CRC checksum. In addition, various packets may be used to hold other information, such as header information or length indications, in the packets of the packet. Note that in some embodiments, the terms may be different, e.g., a packet may be referred to as a byte, with a sequence of bytes referred to as a packet. Of course, other sized sequence blocks may be used in other embodiments, such as nibble, word, doubleword, or other block sizes.

At block 306, the process may include identifying, by the slave node, a checksum value based on the content of the packet. In an embodiment, as described above, the slave node 102 of fig. 1 may calculate a checksum of the packet based on the content of the individual packet.

At block 308, the process may include repeating, by the slave node, transmission of the sequence of packets to the master node until a request to stop transmission is received from the master node. In an embodiment, the slave node 102 of fig. 1 repeatedly transmits a sequence of packets from block 304 to the master node 104. In an embodiment, each packet may be sent on a clock pulse of clock 106. This repeated transmission will continue until a notification from the slave node 104 is received by the slave node 102. In embodiments, this may be a stop message 112, or the clock pulse 106 may be stopped. Note that such continuous or repeated transmissions may have only one or a small number of packets or other blocks until a stop is indicated.

Fig. 4 illustrates an example process for implementing repetition sequential packet reception in a master device using checksum comparison in accordance with an embodiment. The process 400 may be performed by the master node 104 when the master node 104 communicates with the slave node 102 (as shown and described with respect to fig. 1). The process 400 may be implemented by the main operation module 719 of the computing device 700 of fig. 7. Although this embodiment is shown from the perspective of a host device, any device may perform process 400 to receive and process packets according to one embodiment. That is, any device that receives a packet with retransmission information may perform this process, not just the master node that receives the duplicate transmissions from the slave node.

At block 402, the process may include transmitting, by a master node, a request to a slave node to transmit a packet. In an embodiment, this may be performed by the master node 104 sending a request 108 for transmission to the slave node 102.

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

At block 406, the process may determine whether a packet has been received. In an embodiment, the master node 104 may determine whether a packet including all individual packets has been received. In an embodiment, this may be determined based on a comparison of the number of packets received with a packet count sent as part of one of the packets. In other embodiments, this may be determined based on the receipt of a packet or byte sequence identifying the end packet of the packet. Upon determining that a packet has been received, the actions of the following blocks may be performed.

At block 408, the process may include calculating, by the master node, a checksum of the received packet.

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

At block 412, the process may include: when the calculated checksum is not equal to the received checksum, one or more of the received packets are modified based on a comparison of the content of the one or more received packets with the content of the subsequent received packets corresponding to one or more of the repeated packet sequences, respectively. Note that this "modification" can be made by: when the content of this repeated packet differs from its corresponding original packet, the given packet is replaced based on the comparison of the corresponding packets, as determined by the comparison circuitry present in the master node.

Although not shown in fig. 4, it should be appreciated that if the comparison of the calculated and received checksums at block 410 matches, a stop indication may be sent to the slave node to cause it to stop retransmission.

It should also be appreciated that in the event of a checksum mismatch, the master node may cause a decrease in the clock rate. For example, in an I3C implementation, the clock rate may be reduced from 12.5 megahertz (MHz) to 12.0MHz, etc., for the next repeated packet transmission to better ensure accurate transmission. Further, the master node may be configured to perform parallel and/or temporary checksum operations to quickly identify when a completely accurate packet is received.

Referring now to fig. 5, shown is a block diagram of a system in accordance with an embodiment. More specifically, the system 500 illustrated in FIG. 5 represents at least a portion of any of a number of different types of computing devices. In different embodiments, such computing devices may range from relatively small low power devices (e.g., smartphones, tablet computers, wearable devices, etc.) to larger devices (e.g., laptop or desktop computers, server computers, automotive infotainment devices, etc.). In any case, the 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, it should be understood that in other embodiments, bus 515 may be implemented as any type of multi-drop interconnect.

As shown, a primary or primary master 520 is coupled to bus 515. In various embodiments, master 520 may be implemented as a host controller that includes hardware logic to act as a bus master for bus 515. The master 520 may include a controller (high-level view of fig. 5Not shown) to control data (SDA) and clock (SOL). In some cases, master 520 may be a relatively simple host controller for a low complexity bus or other multi-drop bus, e.g., according to I ² C or I3C specifications. Other multi-drop interfaces such as SPI and/or Microwire may also be present in particular embodiments.

In various embodiments, master 520 may be an interface circuit of a multi-core processor or other SoC, application processor, or the like. In other cases, the master 520 may be a stand-alone host controller (e.g., a given integrated circuit (integrated circuit, IC)) or a primary master of the bus 515. And of course other embodiments are possible. In other cases, master 520 may be implemented as hardware, software, and/or firmware, or a combination thereof, such as dedicated hardware logic, e.g., programmable logic, to perform bus master node activities of bus 515.

Note that the 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. Thus, data communication may occur, for example, in a bi-directional manner, while clock communication may occur in a uni-directional manner. The master device 520 may be a relatively computationally complex device (as compared to other devices on the bus 515) that consumes higher power than other devices coupled to the bus 515.

As shown in fig. 5, there are multiple secondary masters 530 ₁ -530 _N . In various embodiments, secondary master 530 may be implemented (generally) as a dedicated master or bridge device, such as a stand-alone IC coupled to bus 515. In other cases, these devices may be independent logic functions of the SoC or other processor (and may in some cases be implemented in the same IC as the master device 520, referred to as a secondary master device). One or more of such secondary masters 530 may be controlled to act as bus master nodes for bus 515 while primary master 520 is in a low power state to enable bus operations to continue while in that low power state.

As further illustrated in fig. 5, a plurality of slave devices 540 ₁ -540 _N Also coupled to bus 515. In different embodiments, the slave device 540 may take many different forms (generally). For purposes of example, the slave device 540 may include one or more of a SoC, network interface circuitry (network interface circuit, NIC), solid state drive (solid state drive, SSD), or other memory such as a dual in-line memory module (dual inline memory module, DIMM), CPU, or other device such as a sensor, point-to-point device, debug device, etc. It should be understood that while shown at this high level in the embodiment of fig. 5, many variations and alternatives are possible.

Referring now to 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, the system 600 may take the form of any type of computing system including at least one slave device 610 and at least one master device 650 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 of the repeated sequential transmissions within these devices for handling a single message or transaction are shown.

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

As further shown, incoming information from the host device 650 may be received via a data line in a receiver 632, which receiver 632 is in turn coupled to the processing circuit 612 via a receive queue 616. As further shown, the incoming clock signal may be received via a clock line in a receiver 635, which receiver 635 is in turn coupled to a clock circuit 628. It should be appreciated that the clock circuit 628 may forward or internally generate one or more clock signals based on the incoming clock signal to provide to the various components of the slave device 610.

As further shown in fig. 6, slave device 610 also includes link control circuitry 620. In addition to acting as an interface to the I3C bus, link control circuit 620 may also include a transmission controller 622, where transmission controller 622 may control the transmission of messages in transmission queue 618. To this end, transmission controller 622 may cause at least a portion of the message (e.g., one or more packets) to be retransmitted from transmission queue 618 until a stop indication is received from master 650. Upon receiving the stop indication (e.g., via a drive that terminates the clock signal), transmit controller 622 may release transmit queue 618 (or at least the message). To enable the duplicate transmissions described herein, the transmission controller 622 may access configuration information in a configuration register 625. Such information may include an enable indicator for the retransmission mode that, when set, indicates that an extended transaction (i.e., repeating one or more portions of the transmission message until a stop indication is received) is to be sent. In an embodiment, link control circuitry 620 may generate one or more checksum values to communicate using packets.

Referring now to master 650, there is processing circuitry 652 that may send commands and other information to slave 610 via driver 656. In turn, processing circuitry 652 may receive incoming information from slave device 610 via receiver 658. As further shown, the master device 650 also includes link control circuitry 670.

In an embodiment, link control circuitry 670 may perform various operations including checking for errors in incoming transactions and stopping retransmission when there are no errors, as described herein. To this end, the link control circuitry 670 includes comparator circuitry 672 that can compare the original and retransmitted corresponding packets or other portions of the message to identify when the portions are different. When different, the retransmitted portions may be provided to one or more checksum circuits 674 _0-n For calculating a new checksum to verify when the packet was received correctly, as described herein. The comparator circuit 672 may also be configured to compare the received checksum with the calculated checksum to determine whether the packet was received correctly. In other embodiments, the computing circuitry may be configured to perform both checksum manipulation and comparison operations.

With further reference to fig. 6, master 650 also includes a clock generator 660, where clock generator 660 may generate a clock signal that is sent to slave 610 via driver 665. In an embodiment, the link control circuitry 670 may also include a clock controller 675 that may control the clock generator 660 to reduce the frequency of the clock signal during the retransmission portion of the packet, as described herein. It should be understood that while shown at this high level in the embodiment of fig. 6, many variations and alternatives are possible.

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

Computing device 700 can include mass storage 706 (e.g., floppy disk, hard drive, volatile memory (e.g., dynamic random-access memory, DRAM), compact disk read-only memory (CD-ROM), digital versatile disk (digital versatile disk, DVD), etc.) generally, system memory 704 and/or mass storage 706 can be any type of temporary and/or persistent storage including, but not limited to, volatile and nonvolatile memory, optical, magnetic, and/or solid-state mass storage, etc., volatile memory can include, but is not limited to, static and/or dynamic random-access memory, nonvolatile memory can include, but is not limited to, electrically erasable programmable read-only memory, phase-change memory, resistive memory, etc.

Computing device 700 can also include I/O devices 708 (e.g., a display (e.g., a touch screen display), keyboard, cursor control, remote control, game controller, image capture device, camera, one or more sensors, etc.) and communication interfaces 710 (e.g., a network interface card, serial bus, modem, infrared receiver, radio receiver (e.g., bluetooth), etc.).

The communication interface 710 may include a communication chip (not shown) that may be configured to operate the device 700 according to a global system for mobile communications (Global System for Mobile Communication, GSM), general packet radio service (General Packet Radio Service, GPRS), universal mobile telecommunications system (Universal Mobile Telecommunications System, UMTS), high speed packet access (High Speed Packet Access, HSPA), evolved HSPA (E-HSPA), or Long Term Evolution (LTE) network. The communication chip may also be configured to operate in accordance with enhanced data for GSM evolution (Enhanced Data for GSM Evolution, EDGE), GSM EDGE radio access network (GSM EDGE Radio Access Network, GERAN), universal terrestrial radio access network (Universal Terrestrial Radio Access Network, UTRAN), or Evolved UTRAN (E-UTRAN). The communication chip may be configured to operate in accordance with code division multiple access (Code Division Multiple Access, CDMA), time division multiple access (Time Division Multiple Access, TDMA), digital enhanced cordless telecommunications (Digital Enhanced Cordless Telecommunications, DECT), evolution-Data Optimized (EV-DO), derivatives thereof, and any other wireless protocol designated as 3G, 4G, 5G, and higher.

The elements of computing device 700 described above may be coupled to each other via a system bus 712. The system bus 712 represents a variety of buses, including, for example, I3C, wherein one or more of the processor 702, memory 704, mass storage 706, communication interface 710, and I/O devices 708 may be master or slave devices communicating with each other via the system bus 712.

Thus, these devices may have a slave operating module 718 and/or a master operating module 719, respectively, incorporated therein. In an embodiment, the slave operating module 718 and/or the master operating module 719 may be implemented in hardware or firmware. In particular, they may be within a system incorporating the teachings of the present disclosure to achieve repeated sequential packet transmission, as previously described. In the case of multiple buses, they may be bridged by one or more bus bridges (not shown).

Each of these elements may perform its conventional functions known in the art, except for the incorporated teachings of the present disclosure. In particular, the system memory 704 and mass storage device 706 may be used to store a working copy and a permanent copy of the programming instructions for the operation of the various components of the computing device 700, including, but not limited to, the operating system, one or more applications, and/or system software/firmware of the computing device 700, collectively referred to as computing logic 722, supporting the practice of the present disclosure. The computation logic 722 may be implemented by assembler instructions supported by the processor(s) 702 or high-level languages that may be compiled into such instructions.

A permanent copy of the programming instructions may be placed into mass storage device 706 at 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 with an implementation of the agent program may be employed to distribute the agent and program the various computing devices.

The number, capabilities, and/or capacities of

elements

702, 704, 706, 708, 710, and 712 may vary depending on whether computing device 700 is used as a fixed computing device (e.g., a set-top box or a desktop computer) or a mobile computing device (e.g., a tablet computing device, a laptop computer, a gaming terminal, or a smartphone). Their constitution is otherwise known and will therefore not be described further.

In an embodiment, at least one of the processors 702 may be packaged with computing logic 722, a slave operation module 718, and/or a master operation module 719 configured to practice aspects of the embodiments described herein to form a System-in-package (System in Package, siP) or a System-on-Chip (SoC).

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 (personal digital assistant, PDA), an ultra mobile PC, a cell phone, a digital camera, or an IoT user device. In further implementations, the computing device 700 may be any other electronic device that processes data.

Fig. 8 depicts a computer-readable storage medium that may be used in conjunction with a computing device 700, according to various embodiments. Diagram 800 illustrates an exemplary non-transitory computer-readable storage medium 802 having instructions configured to practice all or selected operations associated with the above-described processes. As shown, the non-transitory computer-readable storage medium 802 may include a plurality of programming instructions 804 (e.g., including a slave operation module 718 and/or a master operation module 719). The programming instructions 804 may be configured to cause a device (e.g., a component of the computing device 700) to perform one or more operations of the processes described with reference to fig. 1-7 in response to execution of the programming instructions by a controller of the component. In alternative embodiments, programming instructions 804 may alternatively be disposed on a plurality of non-transitory computer readable storage media 802. In other embodiments, the programming instructions 804 may be encoded in a transitory computer readable signal.

The following examples relate to further embodiments.

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

In one example, the method further comprises: the checksum value is incorporated into one or more packets in the sequence of packets.

In one example, incorporating the checksum value includes incorporating a first checksum value of a header portion of the packet and incorporating a second checksum value of a payload portion of the packet.

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

In one example, the reception by the first device and the transmission by the first device are controlled by a clock signal received by the first device and transmitted from the second device.

In one example, the indication to stop transmission further comprises stopping the clock signal.

In one example, the method further comprises: continuing to transmit the at least a portion of the sequence of packets at a second clock rate, the second clock rate being slower than the first clock rate at which the sequence of packets is transmitted.

In one example, the method further comprises: a transmission buffer of the first device is released in response to an indication to stop transmission.

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

In another example, a computer readable medium comprising instructions for performing a method of any of the above examples.

In another example, a computer-readable medium comprising data is to be used by at least one machine to fabricate at least one integrated circuit to perform the method of any of the examples above.

In yet another example, an apparatus includes means for performing the method of any of the above examples.

In another example, an apparatus includes: a receiver for receiving a transmission of a packet formed from a sequence of packets from a first device; and at least one calculation circuit for calculating a checksum of the packet and comparing the calculated checksum with a received checksum of the packet. In response to the calculated checksum not being equal to the received checksum, the apparatus is configured to modify one or more received packets based on a comparison of the one or more received packets with one or more corresponding subsequently received packets, respectively, of the retransmission of at least a portion of the sequence of packets of the packet.

In one example, the apparatus is to modify the received one or more packets, including replacing a first packet in the sequence of packets with a retransmitted first packet in the sequence of packets, and causing the first device to continue retransmitting the at least a portion of the sequence of packets.

In one example, in response to the calculated checksum equaling the received checksum, the apparatus is to transmit an indication to the first device to cease retransmitting the packet.

In one example, the at least one computing circuit is configured to compute a plurality of checksums in parallel, each of the plurality of checksums for a different combination of received packets in the sequence of packets, including one or more retransmitted packets.

In one example, the apparatus further comprises: a clock generator for transmitting a clock signal to the first device, wherein in response to the calculated checksum not being equal to the received checksum, the apparatus causes the clock generator to transmit the clock signal at a lower clock rate.

In one example, the apparatus is to: calculating a header checksum for a header portion of the packet and comparing the header checksum with a received header checksum; and if the header checksum is not equal to the received header checksum, causing the first device to cease transmitting the sequence of packets.

In another example, a system includes: a first device for coupling to an interconnect, the first device comprising: a first driver for driving first information onto a first line of the interconnect; a first receiver for receiving incoming information via the first line; and another driver for driving a clock signal onto a second line of the interconnect. The first device is configured to: receive a message from the second device via the first line; and calculating a checksum for the message and comparing the checksum with the received checksum of the message and causing the second device to continue retransmitting one or more portions of the message until it is determined that the checksum matches the received checksum.

The second device is coupled to the first device via the interconnect, the second device comprising: a second receiver; a second driver; and a control circuit. The control circuit is used for: determining a sender-side checksum of the message and including the sender-side checksum in the message as a received checksum; and sending the message via the second driver and continuing to send one or more portions of the message to the first device until an indication to cease transmission is received.

In one example, the second device is configured to send the message and continue to send one or more portions of the message as a single extended transaction.

In one example, the one or more portions of the message include a byte-sized block.

In one example, the indication to stop transmission includes deactivation of the clock signal on the second line.

In one example, the first device further comprises a clock generator to generate the clock signal, wherein in response to the calculated checksum not being equal to the received checksum, the clock generator is to generate the clock signal at a lower clock rate and the other driver is to drive the clock signal onto the second line of the interconnect at the lower clock rate.

In another example, an apparatus, comprising: means for receiving a request for transmitting a packet, the packet formed from a sequence of packets; generating a checksum value based on the sequence of packets; and means for transmitting the sequence of packets to a requestor and continuing to transmit at least a portion of the sequence of packets until an indication to stop transmission is received from the requestor.

In one example, the apparatus further comprises means for incorporating the checksum value into one or more packets in the sequence of packets.

In one example, the apparatus further comprises means for receiving a clock signal from the requestor.

In one example, the indication to stop transmission includes stopping the clock signal.

In one example, the means for transmitting is for transmitting the sequence of packets at a first clock rate and for continuing to transmit the at least a portion of the sequence of packets at a second clock rate, the second clock rate being slower than the first clock rate.

It should be appreciated that various combinations of the above examples are possible.

Various embodiments may include any suitable combination of the above-described embodiments, including alternative (or) embodiments to those described above in conjunction (and) (e.g., "and" may be "and/or"). Further, some embodiments may include one or more articles of manufacture (e.g., a non-transitory computer readable medium) having instructions stored thereon that, when executed, result in actions of any of the above embodiments. Further, some embodiments may include an apparatus or system having any suitable means for performing the various operations of the embodiments described above.

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

These modifications can be made to the embodiments of the disclosure in light of the above detailed description. The terms used in the following claims should not be construed to limit the various embodiments of the 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.

These modifications can be made to embodiments of the disclosure in light of the above detailed description. The terms used in the following claims should not be construed to limit the various embodiments of the 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.

Claims

1. A method, comprising:

receiving, by a first device, a request from a second device to transmit a packet, the packet formed from a sequence of packets;

generating, in the first device, a checksum value based on the sequence of packets; and

transmitting, by the first device, the sequence of packets to the second device, and continuing to transmit at least a portion of the sequence of packets until an indication to stop transmission is received from the second device.

2. The method of claim 1, further comprising: the checksum value is incorporated into one or more packets in the sequence of packets.

3. The method of claim 2, wherein incorporating the checksum value comprises: a first checksum value incorporated into a header portion of the packet and a second checksum value incorporated into a payload portion of the packet.

4. The method of claim 1, further comprising:

determining, by the first device, a number of packets within the packet; and

an indication of the determined number of packets within the packet is incorporated into one or more of the packets of the packet.

5. The method of claim 1, wherein the receiving by the first device and the transmitting by the first device are controlled by a clock signal received by the first device and transmitted from the second device.

6. The method of claim 5, wherein the indication to stop transmission further comprises stopping the clock signal.

7. The method of claim 1, further comprising: continuing to transmit the at least a portion of the sequence of packets at a second clock rate, the second clock rate being slower than the first clock rate at which the sequence of packets is transmitted.

8. The method of claim 1, further comprising: a transmission buffer of the first device is released in response to the indication to stop transmission.

9. The method of claim 1, wherein transmitting the sequence of packets and continuing to transmit the at least a portion of the sequence of packets comprises a single transaction.

10. An apparatus, comprising:

a receiver for receiving a transmission of a packet formed from a sequence of packets from a first device; and

at least one calculation circuit for calculating a checksum of the packet and comparing the calculated checksum with a received checksum of the packet;

wherein, in response to the calculated checksum not being equal to the received checksum, the apparatus is to modify one or more received packets based on a comparison of one or more of the received packets with one or more corresponding subsequently received packets of the retransmission of at least a portion of the sequence of packets of the packet, respectively.

11. The apparatus of claim 10, wherein the means for modifying the one or more of the received packets comprises: replacing a first packet in the sequence of packets with a retransmitted first packet in the sequence of packets, and causing the first device to continue retransmitting the at least a portion of the sequence of packets.

12. The apparatus of claim 10, wherein in response to the calculated checksum being equal to the received checksum, the apparatus is configured to transmit an indication to the first device to cease retransmitting the packet.

13. The apparatus of claim 10, wherein the at least one computing circuit is configured to compute a plurality of checksums in parallel, each of the plurality of checksums for a different combination of received packets in the sequence of packets, the received packets comprising one or more retransmitted packets.

14. The apparatus of claim 10, further comprising: a clock generator for transmitting a clock signal to the first device, wherein in response to the calculated checksum not being equal to the received checksum, the apparatus is configured to cause the clock generator to transmit the clock signal at a lower clock rate.

15. The apparatus of claim 10, wherein the apparatus is configured to:

calculating a header checksum of a header portion of the packet and comparing the header checksum with the received header checksum; and

and if the header checksum is not equal to the received header checksum, causing the first device to cease transmitting the sequence of packets.

16. A system, comprising:

a first device for coupling to an interconnect, the first device comprising:

a first driver for driving first information onto a first line of the interconnect;

a first receiver for receiving incoming information via the first line;

another driver for driving a clock signal onto a second line of the interconnect;

wherein the first device is configured to:

receive a message from the second device via the first line; and

calculating a checksum of the message and comparing the checksum of the message to a received checksum and causing the second device to continue retransmitting one or more portions of the message until it is determined that the checksum matches the received checksum;

the second device coupled to the first device via the interconnect, the second device comprising:

a second receiver;

a second driver; and

a control circuit, wherein the control circuit is configured to:

determining a sender-side checksum of the message and including the sender-side checksum in the message as the received checksum; and

The message is sent via the second driver and one or more portions of the message continue to be sent to the first device until an indication to stop transmission is received.

17. The system of claim 16, wherein the second device is to send the message and continue to send the one or more portions of the message as a single extended transaction.

18. The system of claim 16, wherein the one or more portions of the message comprise byte-sized blocks.

19. The system of claim 16, wherein the indication to cease transmission comprises deactivation of the clock signal on the second line.

20. The system of claim 16, wherein the first device further comprises a clock generator to generate the clock signal, wherein in response to the calculated checksum not being equal to the received checksum, the clock generator is to generate the clock signal at a lower clock rate and the other driver is to drive the clock signal onto the second line of the interconnect at the lower clock rate.

21. An apparatus, comprising:

Means for receiving a request for transmitting a packet, the packet formed from a sequence of packets;

generating a checksum value based on the sequence of packets; and

transmitting the sequence of packets to a requester and continuing to transmit at least a portion of the sequence of packets until an indication to stop transmission is received from the requester.

22. The apparatus of claim 21, further comprising: and means for incorporating the checksum value into one or more packets in the sequence of packets.

23. The apparatus of claim 21, further comprising: means for receiving a clock signal from the requestor.

24. The apparatus of claim 23, wherein the indication to cease transmission comprises ceasing the clock signal.

25. The apparatus of claim 24, wherein the means for transmitting is configured to transmit the sequence of packets at a first clock rate and to continue transmitting the at least a portion of the sequence of packets at a second clock rate, the second clock rate being slower than the first clock rate.