Architecture for preventing deadlock between controllers

Abstract

An integrated circuit chip includes a secondary controller coupled to a deadlock solver that provides a communication interface with a primary controller. The deadlock solver stores executable control logic for detecting a reset event indicator on the secondary controller that indicates a reset event pattern executed on the secondary controller when the secondary controller is in a reset state. Based at least in part on the detection of the reset event indicator, the deadlock solver transmits to the secondary controller a signal pattern that simulates transactions of the primary controller that assists the secondary controller in exiting the reset state.

Description

Background Art

[0001] Inter-Integrated Circuit (better known as "I2C") is a serial communication protocol introduced in the 1980s that simplifies the hardware connections between devices on a connected embedded system by limiting the number of wires required to just two: a serial data (SDA) line and a serial clock (SCL) line. The SDA line is used to transmit data between a master device and slave devices coupled to the bus, while the SCL line synchronizes the data transfer between the master and slave devices.

[0002] The I3C protocol is a standardized protocol designed to overcome some of the limitations of I2C, such as by enabling faster data transfer speeds and making operation more energy-efficient. The I3C communication bus includes many of the same components as the I2C bus, including two main bus lines (SDA and SCL) and various controllers, each of which facilitates communication on behalf of a respective device coupled to the I3C bus. These controllers come in two different types: master controllers (sometimes referred to as "controllers") and slave controllers (sometimes referred to as "targets"), each of which includes a microprocessor executing firmware capable of interpreting and transmitting the I3C protocol's predefined set of communications across the I3C bus. Summary of the Invention

[0003] In one implementation, an integrated circuit (IC) chip includes a secondary controller coupled to a deadlock resolver that provides a communication interface with a primary controller. The deadlock resolver stores control logic executable to detect a reset event indicator that indicates a reset event pattern to be executed on the secondary controller when the secondary controller is in a reset state. In response to the reset event indicator, the deadlock resolver transmits a signal pattern to the secondary controller that simulates a transaction from the primary controller. The signal pattern assists the secondary controller in exiting the reset state.

[0004] This summary is intended to introduce some concepts in a simplified form that will be further described in the detailed implementation method below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] Other implementations are also described and listed herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 An example I3C system is shown that includes an integrated circuit chip having a hot join deadlock resolver that prevents hot join deadlock between a primary controller (eg, a master controller) and a secondary controller (eg, a slave controller).

[0007] Figure 2 Aspects of another example system including a hot join deadlock resolver to prevent hot join deadlock scenarios on an I3C bus are shown.

[0008] Figure 3 A pair of serial data (SDA) and serial clock (SCL) signals are shown including example event types that may be used to safely trigger switching of a slave controller's clock input between two different clock sources.

[0009] Figure 4 Example operations for preventing deadlock following a slave device reset in an IC3 bus are shown.

[0010] Figure 5 An example schematic diagram of a processing device suitable for implementing aspects of the disclosed technology is shown. DETAILED DESCRIPTION

[0011] A significant improvement offered by the I3C protocol over the I2C protocol is the dynamic addressing feature, which allows the master I3C controller to assign a 7-bit dynamic address to each connected slave device on the I3C bus. In the I2C bus, device addressing is static, and each I2C device is typically assigned a static address during production. This practice leads to the problem of duplicate addresses potentially existing on the same bus. In I3C, this duplicate addressing problem is eliminated due to the fact that each I3C slave device receives a unique address from the master device.

[0012] In the I3C bus, slave device addresses are dynamically assigned when the I3C bus is initially powered on and configured. However, another significant improvement in I3C is a feature that allows devices to join the I3C bus and request dynamic addresses at any point after the I3C bus is powered on and configured. This feature is called the "hot join" mechanism and is invoked when a joining slave device sends an in-band interrupt (IBI) request across the bus. This IBI request marks the beginning of the "hot join process," during which a series of communications are exchanged between the master device and the joining slave device to dynamically assign addresses to the slave devices. This address assignment allows the slave device to fully participate in I3C bus activities.

[0013] To send an IBI request to initiate the hot join process, the newly joined device waits to detect a bus idle condition and then pulls the SDA line low (e.g., from 1 to 0). This serves to notify the master controller (also referred to herein as the "primary controller") that a new device has joined the bus, and the master controller responds by pulling the SCL line low to generate a start condition, followed by an additional signal communication sequence that affects dynamic address allocation.

[0014] The technology disclosed herein provides a solution to a shortcoming in the existing I3C protocol, which can, in certain circumstances, prevent a slave device from effectively initiating a hot join process. In order to initiate the hot join process (e.g., by detecting the bus idle condition mentioned above and pulling the SDA line low), the slave device must first be powered on and fully operational. When a slave device is first powered on, the associated slave controller executes a default reset mode, which includes an internal reset synchronized with the master controller's clock. While executing the reset mode, the slave device is said to be in a "reset state." Once the reset mode is successfully executed to completion, the slave device "exits" the reset state. One step in this reset sequence includes resetting the slave controller, which is synchronized with the master controller's SCL clock. This clock synchronization is not instantaneous and typically takes several clock cycles to complete. Specifically, the slave controller needs to observe several (e.g., three or more) pulse edges of the master controller's clock signal to complete the synchronization that allows the slave controller to exit the reset state. This means that if the master controller's clock is idle (e.g., in sleep mode), the slave controller cannot exit the reset state. In these scenarios, the slave device is effectively "stuck" in reset indefinitely.

[0015] In the vast majority of scenarios, the hot join process is invoked when there is already a slave device coupled to the I3C bus and actively communicating with the master device. In these scenarios, the master controller's clock is in an active switching state, so any device attempting to hot join can perform the time synchronization step of the reset mode without problems. However, there are scenarios where the master controller's clock is idle (e.g., held in the 0 state). For example, if the I3C bus is initialized when no slave device is coupled to the bus, the master controller attempts to dynamically assign addresses to listening slave devices during bus initialization. However, when no slave device is coupled to the bus, the master controller does not receive a response to the address assignment attempt. Therefore, the master controller enters sleep mode until the slave device subsequently initiates the hot join process.

[0016] In sleep mode, the master controller's clock is typically maintained in an idle state to save power. This means that the clock signal is not switched on the SCL line output from the master controller, so any slave device attempting to exit the reset state cannot perform the clock reset step required to complete its reset mode. This scenario is referred to as "hot join deadlock" in this article - meaning that the hot join process cannot be initiated and the slave device cannot join the bus. A possible solution to this "hot join deadlock" problem is to program the master controller to periodically issue transactions (e.g., every 30 seconds or at other repetitive intervals), thereby essentially "inviting" the slave device to initiate a hot join process. However, this solution is extremely energy-inefficient because it relies on waking up the host (master) device at repeated intervals, even if there is no device waiting to hot join the bus.

[0017] The disclosed technology includes hardware and control logic, referred to herein as a "deadlock resolver," which provides an interface between a master controller and a slave controller. Each time the slave controller executes a default reset mode, the deadlock resolver provides a signaling pattern to the slave controller that simulates an I3C transaction from the master controller. As a result, the slave controller receives an SCL signal input that can be used to perform the clock reset operation required to successfully complete the default reset mode of the slave device. In effect, this "simulated" transaction allows the slave controller to successfully complete the reset mode and exit the reset state at any time, even if the master controller has not switched its clock. In this way, the deadlock resolver prevents the hot join "deadlock" scenario described above in an energy-efficient manner.

[0018] In one implementation, the deadlock resolver additionally performs actions to safely switch the source input signals of the slave controller from on-chip sources (e.g., the data generation source and clock of the deadlock resolver) back to the externally sourced main bus signals (e.g., those generated by the master controller). This is particularly important for the SCL input because if the slave controller locks the SCL signal at the moment when the SCL signal transitions from low to high or from high to low, it is very likely to cause a hardware failure, thereby causing an unknown state or metastable state of the digital circuit. This type of failure can generate a system error that requires power cycling or various diagnostics to effectively remedy. To ensure system stability, it is critical that the deadlock resolver performs a switch back to the externally sourced SCL signal when the SCL signal is stable.

[0019] Figure 1 An example I3C system 100 is shown that includes an integrated circuit chip 102 having a hot-join deadlock resolver 104 for preventing hot-join deadlocks. The I3C system 100 includes a master device 106 that communicates via a primary controller 110 (e.g., a master controller) across an I3C bus 112. In various architectures, the primary controller 110 can be integrated with the master device 106 (e.g., on the same chip) or otherwise communicatively coupled to the master device 106.

[0020] The I3C system 100 is also shown to include a plurality of slave devices, including a slave device 116, a slave device 118, and a slave device 120. Each of the slave devices 116, 118, and 120 communicates across the I3C bus 112 through a corresponding slave controller, also referred to herein as an "auxiliary controller" (e.g., one of the auxiliary controllers 124, 126, and 128). In various architectures, each of the auxiliary controllers 124, 126, and 128 is either integrated with its associated slave device (e.g., formed within the slave device or on the same chip as shown) or is otherwise communicatively coupled to the other associated slave devices.

[0021] The primary controller 110 transmits signals across the I3C bus on behalf of the master device, and each of the secondary controllers 124, 126, and 128 transmits signals across the I3C bus on behalf of an associated slave device (e.g., one of the slave devices 116, 118, and 120). In one implementation, the primary controller 110 and each of the secondary controllers 124, 126, and 128 include a memory that stores firmware and a microprocessor that executes the firmware instructions to interpret a defined set of I3C communications, thereby facilitating data transfer between the master device 106 and each of the slave devices 116, 118, and 120.

[0022] exist Figure 1 , the slave device 120 is shown as being communicatively coupled to the hot join deadlock resolver 104. The hot join deadlock resolver 104 provides an interface between the slave device 120 and the I3C bus 112, which receives communications from the master device 108. The hot join deadlock resolver 104 includes control logic implemented in hardware, firmware, or a combination thereof, and a component for executing the control logic (e.g., a microprocessor if the control logic is implemented in software).

[0023] exist Figure 1 In the embodiment of the present invention, the hot join deadlock resolver 104 is formed on an integrated circuit chip 102, which also includes the slave device 120 and the auxiliary controller 128. This architecture is not required, and in some implementations, the hot join deadlock resolver 104 is not formed on the same IC chip as the slave device it supports. For example, the hot join deadlock resolver 104 is formed on a separate chip designed to provide a communication interface between the slave device 120 and the master device 106. In another implementation, the hot join deadlock resolver 104 is formed on a PCB that supports the master device 106 and is packaged with the master device 106 in a housing that includes a port designed to removably couple the slave device 120.

[0024] The I3C bus 112 includes a serial data (SDA) line for communicating data signals and a serial clock (SCL) line for synchronizing data transfers between the master device 106 and each of the slave devices 116, 118, and 120. To distinguish these master bus SCL and SDA signals from signals originating from the hot join deadlock resolver 104, these master bus signals are Figure 1 1 and are referred to herein as “off-chip SDA 130 ” and “off-chip SCL 132 ,” where the term “off-chip” means that these signals originate from locations external to the integrated circuit chip 102 .

[0025] The hot-join deadlock resolver 104 executes control logic that assists the auxiliary controller 128 in completing the reset mode each time a reset event occurs on the slave device 120. For example, the auxiliary controller 128 automatically initiates the execution of the reset mode when the slave device 120 starts up after a power cycle or when the integrated circuit chip 102 is physically coupled to the bus 112 for the first time.

[0026] The hot join deadlock resolver 104 includes logic to detect a reset event indicator on the auxiliary controller 128. The reset event indicator includes one or more signals generated on the slave device 120 during reset mode that indicate a reset of the auxiliary controller 128 (e.g., the reset event indicator is detectable only when the auxiliary controller 128 is executing reset mode). In one implementation, the reset event indicator is detected when the auxiliary controller 128 executes a firmware command to turn on the SCL line input to the slave device 120. In another implementation, the event reset indicator is detected when the auxiliary controller 128 transmits an implicit firmware command. In yet another implementation, the event reset indicator is detected when a rising edge is observed on the reset pin of the auxiliary controller 128.

[0027] In response to detecting the reset event indicator on the slave controller 128, the hot join deadlock resolver 104 transmits a signal pattern to the secondary controller 128 that simulates a transaction that the secondary controller 128 expects to receive from the primary controller 110. Notably, the secondary controller 128 includes an input interface that includes a single SDA input that receives an SDA signal 138 and a single SCL input that receives an SCL signal 140. To simulate the transactions of the primary controller 110, the hot join deadlock resolver 104 assumes temporary control of the input interface of the secondary controller 128 and drives the SDA signal 138 and the SCL signal 140 locally from the integrated circuit chip 102, rather than providing external master bus signals (e.g., off-chip SDA 130 and off-chip SCL 132) to the slave controller 128 instead of being sourced on the integrated circuit chip 102. Temporarily, the hot-join deadlock resolver 104 locally drives the SDA signal 138 and the SCL signal 140 to create a signal pattern that the auxiliary controller 128 can in turn identify and safely utilize to reset the internal clock as part of the reset mode. In effect, these locally driven signals simulate a transaction that assists the auxiliary controller 128 in exiting the reset state.

[0028] In addition to emulating transactions from the primary controller 110, the hot-join deadlock resolver 104 also implements control logic to safely switch the sources of the SDA signal 138 and the SCL signal 140 back to the sources driving the off-chip master bus signals (e.g., off-chip SDA 130 and off-chip SCL 132) after the secondary controller 128 exits reset. Switching the source of the SDA signal 138 is less problematic than switching the source of the SCL signal 140 due to hardware sensitivity that can cause hardware failures if the internal clock of the secondary controller 128 locks onto the new clock signal at the exact moment a signal transition occurs. For example, if the primary controller 110 clock transitions from 0 to 1 or vice versa at the exact moment the source of the SCL signal 140 is switched back to the clock (e.g., external SCL 132), this can cause the secondary controller 128 to lock up, resulting in a hardware failure that can cause system errors.

[0029] To this end, it is critical to switch the source of the SCL signal 140 when it is known that the newly received clock signal will remain stable for a duration that exceeds the duration required to resynchronize the internal clock of the auxiliary controller 128 (also known as the "slave clock synchronization time"). To achieve this guarantee, the hot join deadlock resolver 104 monitors the off-chip SDA 130 and off-chip SCL 132 and waits to detect the start of a predefined event type that is known to have a duration that exceeds the clock synchronization time. Examples of predefined event types suitable for this purpose will be referred to as Figure 3 to discuss.

[0030] After auxiliary controller 128 completes the reset mode and transitions from the reset state to the normal operating state, it initiates the hot join process. Specifically, auxiliary controller 128 monitors signals from the off-chip clock and off-chip data source and waits for these signals to meet the bus idle condition. When the bus idle condition is met, auxiliary controller 128 pulls off-chip SDA 130 to a zero state and waits for primary controller 110 to assign a dynamic address to auxiliary controller 128 by performing further operations consistent with the I3C protocol.

[0031] Figure 2 Aspects of another example system 200 are shown that includes a hot join deadlock resolver 202 to prevent a hot join deadlock scenario on an I3C bus. The hot join deadlock resolver 202 includes hardware or a combination of hardware and software configured to perform actions that assist an auxiliary controller 218 (e.g., a slave controller coupled to a slave device) in completing a reset mode, which effectively enables the slave device 206 to exit a reset state.

[0032] In one implementation, the hot join deadlock resolver 202 is integrated into a Figure 1 2. The system 200 is a block diagram of a larger system having the same or similar architectural features as shown in FIG. 2. Assume that the system 200 includes an I3C bus with a primary controller (e.g., a controller coupled to a master device). The I3C bus includes a first communication line for transmitting an SDA signal (shown as off-chip SDA 207) and also includes a second communication line for transmitting a clock signal (shown as off-chip SCL 208). The primary controller includes a clock that drives off-chip SCL 208. All controllers on the I3C bus have the ability to transmit data across the primary SDA line; therefore, off-chip SDA 207 may originate from the primary controller or any other controller on the I3C bus at a given point in time.

[0033] Hot join deadlock resolver 202 includes two main logical components, including transaction simulation 210 and secure SCL multiplexing (mux) controller 212. In various implementations, transaction simulation 210 and secure SCL multiplexing controller 212 include hardware or a combination of hardware and software. Hot join deadlock resolver 202 also includes a first switching circuit system represented by a first multiplexer 214 and a second switching circuit system represented by a multiplexer 216.

[0034] The first multiplexer 214 is configured to selectively switch the data input source of the SDA signal 220 provided to the auxiliary controller 218. When the multiplexer 214 selects "1" as the data input source, the SDA signal 220 output by the multiplexer 214 is a signal generated by an off-chip data source (e.g., any controller currently generating the SDA signal propagating along the main I3C bus). When the multiplexer 214 is switched to select "0" as the data input source, the SDA signal 220 output by the multiplexer 214 is a signal generated by a data source located on the same chip as the hot-join deadlock resolver 202 (referred to herein as an "on-chip data source"), which data source can be conceptually understood as being included within the transaction simulation 210.

[0035] The second multiplexer 216 is configured to selectively switch the clock input source of the SCL signal 222 provided to the auxiliary controller 218. When the multiplexer 216 selects "1" as the clock input source, the SCL signal 222 output by the multiplexer 216 is a clock signal originating from and driven by the primary controller (e.g., off-chip with respect to the hot-join deadlock resolver 202). When the multiplexer 216 selects "0" as the clock input source, the SCL signal 222 output by the multiplexer 216 is a signal originating from an on-chip data source, which can be understood as a clock included in and driven by the transaction simulation 210.

[0036] In one implementation, the hot join deadlock resolver 202 is configured to select the on-chip SDA and on-chip SCL sources by default whenever the slave device is powered on after exiting a reset state. For example, during a power-down sequence of the slave device 206 or whenever the connection to the auxiliary controller 218 is interrupted, the hot join deadlock resolver 202 switches the multiplexers 214 and 216 to select the on-chip data source so that the on-chip SDA and on-chip SCL are automatically selected whenever the slave device 206 is first powered on. Therefore, when the slave device 206 is first powered on, the SDA signal 220 and the SCL signal 222 both originate from the source driven by the hot join deadlock resolver 202. In another implementation, the hot join deadlock resolver 202 selectively switches the multiplexers 214 and 216 to select the on-chip clock and data source in response to detecting a reset event indicator, as further described below.

[0037] The transaction simulation 210 monitors the activity of the secondary controller 218 for a reset event indicator, which can be understood as a predefined signal or combination of predefined signals that indicates the execution of a reset mode on the secondary controller 218. In one implementation, the transaction simulation 210 detects the reset event indicator when the secondary controller 218 observes the activation of the clock signal on the slave controller. In other implementations, the reset event indicator is an explicit firmware command transmitted by the secondary controller 218.

[0038] In response to detecting a reset event indicator on the secondary controller 218, the transaction emulation 212 performs a series of operations that transmit an artificial primary communication to the secondary controller 218 in the I3C protocol. This communication is "artificial" in the sense that it simulates the communication that the secondary controller 218 is programmed to receive from the primary controller on the I3C bus, but is clearly not coming from the primary controller. In one implementation, the transaction emulation 212 initiates the artificial transaction by first pulling the SDA signal 220 low (0). After a prescribed period of time has passed in which the SDA signal 220 remains low, the SCL signal 222 is then driven back high (1). In I3C, this action generally represents an initiation transaction start condition. Following this start condition, the transaction emulation 212 begins driving the local (on-chip) clock to toggle the SCL signal 222 for a predetermined number of clock cycles. After a predetermined number of clock cycles, the transaction emulation 212 generates a stop condition by driving the SCL signal 220 high, and then, after a predetermined period of time in which SDA is low and the SCL signal 220 remains high, driving the SDA signal 220 high to indicate the end of the transaction.

[0039] The predetermined number of clock cycles may vary in different implementations, but is long enough to allow the secondary controller 217 to synchronize its internal clock (e.g., at least three clock cycles in length). In one implementation, while SDA 220 is held low, transaction emulation 212 cycles the on-chip clock nine times, thereby issuing nine consecutive zero signals. This cycling of the on-chip clock (driven locally by the hot-join deadlock resolver 202) allows the secondary controller 218 (e.g., a slave controller) to synchronize its own clock—a necessary step in the default reset mode of the I3C slave controller. This synchronization is supported even when the primary controller is idle (which would otherwise prevent the secondary controller 218 from completing clock synchronization and thus failing to successfully complete reset mode), thereby transitioning the secondary controller 218 from reset mode to normal operating mode.

[0040] After transmitting the communication (e.g., simulating communication from the primary controller), the hot join deadlock resolver 202 performs actions to switch the source of the SDA signal 220 and the SCL signal 222 back to the off-chip SDA 207 and the off-chip SCL 208, respectively, to allow the slave device 206 to initiate the hot join process with the primary controller (e.g., receive a dynamic address assignment and allow the slave device 206 to become fully capable of IC3 communication on the IC3 bus). Notably, the switching of the SDA input source can be safely performed at any time without the risk of hardware failure. In one implementation, once the transaction simulation 210 transmits a "stop" signal indicating the end of the initial communication sequence, the transaction simulation 210 switches the SDA select input on the multiplexer 214 to switch the data input source of SDA 220 back to the off-chip data source (e.g., the primary controller or another secondary controller currently transmitting data along the main SDA line of the bus).

[0041] In contrast, if the input clock signal (SCL 222) is switched back to the off-chip SCL 208 while the signal is unstable, there is a small but significant risk of hardware failure within the auxiliary controller 218. That is, if the auxiliary controller 218 attempts to lock onto the new clock signal (e.g., off-chip SCL 208) at the exact moment the new clock signal is switched from low to high or from high to low, this may cause the auxiliary controller 218 to lock up and generate a system error.

[0042] To mitigate this risk, the hot-add deadlock resolver 202 waits until it is certain that the off-chip SCL 208 remains stable for the time it takes the auxiliary controller 218 to lock onto the new clock signal after switching before switching the select input of the multiplexer 216 .

[0043] In one implementation, the secure SCL multiplexer controller 212 implements the above by monitoring one or both of the off-chip SDA 207 and the off-chip SCL 208 to identify a start signature that indicates the "start" of a predetermined event type. In different implementations, the predefined event type can be different; however, the predefined event type is a known (recognized) event that locks to a new clock signal. For example, the time it takes for the auxiliary controller 218 to lock to a new clock signal is approximately 1 nanosecond (e.g., 1 clock tick), and the length of the predefined event type is on the order of tens of nanoseconds or longer. When the secure SCL multiplexer controller 212 sees the start signature of the predefined event type in the off-chip SCL 208 (and / or the off-chip SDA 207), the secure SCL multiplexer controller 212 then immediately switches the selection of the multiplexer 216 to switch the clock source driving the off-chip SCL 208 from the on-chip clock to the off-chip clock (e.g., the primary controller clock). After this action, both SDA 220 and SCL 222 are driven by off-chip sources (external to the hot-join deadlock resolver 202), and the system can operate normally as if the hot-join deadlock resolver 202 was not present in the interface between the slave device 206 and the primary controller.

[0044] Figure 3 A pair of SDA and SCL signals 300 including example event types that can be used to safely trigger the clock input of an auxiliary controller to switch between two different clock sources is shown. Specifically, the SDA and SCL signals 300 include Figure 3 The characteristics that may exist in the off-chip SDA and off-chip SCL signals monitored by the safety multiplexer controller 312.

[0045] As mentioned above about Figure 3 As mentioned, if the duration of the secondary controller's "locking" on the new clock signal overlaps with the clock signal's transition from high to low or low to high, the controller hardware may malfunction and generate a system error. Figure 3 The two events shown represent event types that have uniquely identifiable start signatures and whose duration safely exceeds (eg, exceeds by 25% or more) the known amount of time it takes an I3C controller to latch onto a new SCL signal.

[0046] The example signal 300 includes the start signatures of at least two different types of events, which can be used as the "predefined event types" mentioned above. Figure 2The safe SCL multiplexing controller 212 uses it as a trigger to switch the clock input source provided to the auxiliary controller 222. Specifically, the signal 300 includes a transaction start condition 302, which is characterized in I3C by the SDA line being pulled low when the SCL line is high. According to the mipi I3C standard version 1.0, the I3C start condition is typically maintained for a minimum duration of at least 38.4 nanoseconds, while the stop condition is maintained for a minimum duration of at least 20 nanoseconds, both of which significantly exceed the time it takes for the I3C controller to lock onto a new clock signal (e.g., less than 5 nanoseconds). Therefore, the initiation of a start or stop condition acts as a predefined event type that can be "seen" by the hot join deadlock resolver 202 and used as a timing trigger to safely switch the clock source input to the I3C controller.

[0047] Another example predefined event type that can be used as a trigger for safely switching the source of the I3C controller clock input is the observation of a rising edge (i.e., a rising edge) of a clock signal (e.g., the clock signal of the primary controller). Given that the duration of the issued square clock pulse exceeds the known time it takes for the controller to lock onto the new SCL signal, the observation of the rising edge of the clock pulse is a sufficient indication that the clock signal will remain stable for a sufficient duration to safely achieve lock on the new signal. Therefore, in one implementation, the hot-join deadlock resolver 202 waits to observe a rising edge of the primary clock signal and uses this event as a timing trigger to switch the selection of the SCL multiplexer that provides the clock signal to the secondary controller.

[0048] In other implementations, signatures of other predefined event types may be used as a basis for switching the clock of the auxiliary controller from the on-chip clock to the off-chip clock (e.g., as described above with respect to Figure 2 as described).

[0049] Figure 4 Example operations 400 are shown for preventing deadlock after a slave device reset in an I3C bus. A first detection operation 402 detects a reset event indicator that indicates that a reset mode is being executed on an I3C slave controller that is currently in a reset state. In one embodiment, the reset event indicator is the start of the clock input line of the slave controller, which can be detected by a hot-join deadlock resolver coupled to the slave controller, such as Figure 1 or Figure 2 As shown in the configuration.

[0050] In response to detecting the reset event indicator, the manual transaction operation 404 drives the on-chip clock and the on-chip data source to transmit a signal pattern to the slave controller that simulates a transaction from the master controller. The on-chip clock and the on-chip data source are "on-chip" because they are located on the same chip as the mechanisms that drive the on-chip clock and the on-chip data source. In one implementation, the transmitted signal pattern begins with a valid "start condition", includes a short sequence of data bits that coincide with each of a plurality of clock cycles, and ends with a valid "stop condition". In one implementation, the signal pattern transmitted by the manual transaction operation 404 has the effect of assisting the slave controller in exiting the reset state by providing the slave controller with an input clock signal that can be used to perform the clock synchronization step in the reset mode.

[0051] After the signal pattern is transmitted, the slave controller can self-execute the remainder of the reset mode and exit the reset state. A switching operation 406 switches the data signal (SDA) input to the slave controller from an on-chip data source to an off-chip data source, and a monitoring operation 408 monitors an external (e.g., master bus) signal issued by an off-chip clock (e.g., a master controller) and an off-chip data source (e.g., a master controller or other controller transmitting data along the master bus SDA line) to determine a safe time to switch the clock signal input to the slave controller.

[0052] Based on the monitoring operation 408, a detection operation 410 detects a start signature of a predefined event type. A predefined event type is a recognized event characterized by a duration of a stable (unchanged) clock signal exceeding a defined threshold (e.g., the amount of time it takes for the slave controller to lock onto a new clock signal). For example, the start signature of a predefined event type can be the occurrence of a valid start condition (e.g., when SDA is pulled low and SCL is high). In another implementation, the start signature of a predefined event type is a rising edge of a clock pulse.

[0053] In response to detecting the start signature of a predefined event type, a switching operation 412 switches the selection on the clock signal multiplexer that selects the clock signal input to the slave controller. This switching switches the selected clock signal from the on-chip clock to the off-chip clock. This switching of the clock signal allows the secondary controller 218 to lock onto the clock signal of the primary (master) controller, which is used to synchronize communications sent and received from various devices across the IC3 bus.

[0054] Figure 5An example schematic diagram of a processing device 500 suitable for implementing various aspects of the disclosed technology is shown. In one implementation, processing device 500 is a device that communicates with other processing devices via an I3C bus. In another implementation, processing device 500 includes an I3C bus and multiple devices (e.g., slave device(s) and master device(s)) that communicate with each other via the I3C bus.

[0055] The processing device 500 includes a processing system 502, memory device(s) 504, a display 506, and other interfaces 508 (e.g., buttons). The memory device(s) 504 typically include both volatile memory (e.g., RAM) and non-volatile memory (e.g., flash memory). An operating system 510 may reside in the memory device(s) 504 and be executed by the processing system 502. One or more applications 512 may be loaded into the memory by the processing system 502 and executed on the operating system 510. The processing system 502 may include one or more processors (e.g., CPUs, GPUs) configured to communicate with other processing entities (e.g., subsystems, chips, or computing device accessories) via an I3C bus.

[0056] The processing device 500 includes a power supply 516, which is powered by one or more batteries or other power sources and provides power to the other components of the processing device 500. Additionally, the processing device 500 includes one or more communication transceivers 530 and antennas 532 to provide network connectivity (e.g., mobile phone networks, The processing device 500 may also be coupled (e.g., via an I3C bus or otherwise) to various input devices 534 such as a microphone, keyboard, touch display, etc. In one implementation, the I3C controller logic is stored as firmware that is executed locally by a microprocessor in an I3C controller attached to one or more of the input devices 534, the communication interface 526, components of the processing system 502, or any other components of the processing device 500.

[0057] (Multiple) memory devices 504 can be the memory of a host device or an accessory coupled to a host. The processing device 500 can include various tangible computer-readable storage media and intangible computer-readable communication signals. Tangible computer-readable storage media can be any available media that can be accessed by the processing device 500, including volatile and non-volatile storage media, as well as removable and non-removable storage media. Tangible computer-readable storage media does not include intangible and transient communication signals, but includes volatile and non-volatile, removable and non-removable storage media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Tangible computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage media, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other tangible media that can be used to store the desired information and can be accessed by the processing device 600. In contrast to tangible computer-readable storage media, intangible computer-readable communication signals may embody computer-readable instructions, data structures, program modules, or other data resident in a modulated data signal, such as a carrier wave or other signal transmission mechanism. The term "modulated data signal" refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, intangible communication signals include wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media.

[0058] Some embodiments may include an article of manufacture. An article of manufacture may include a tangible storage medium for storing logic. Examples of storage media may include one or more types of computer-readable media capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, etc. Examples of logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, application programming interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. For example, in one implementation, an article of manufacture may store executable computer program instructions that, when executed by a computer, cause the computer to perform methods and / or operations according to the described embodiments. Executable computer program instructions may include any suitable code type, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, etc. Executable computer program instructions can be implemented according to a predefined computer language, method or syntax to instruct a computer to perform specific functions. These instructions can be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0059] The following overview provides a non-comprehensive set of illustrative examples of the techniques described herein. The example IC disclosed herein includes a deadlock resolver that provides a communication interface between a primary controller and a secondary controller. The deadlock resolver stores control logic executable to detect a reset event indicator on the secondary controller, the reset event indicator indicating a reset event pattern to be executed on the secondary controller when the secondary controller is in a reset state. Based at least in part on the detection of the reset event indicator, the deadlock resolver transmits a signal pattern to the secondary controller that simulates a transaction from the primary controller. The signal pattern assists the secondary controller in exiting the reset state.

[0060] In another example of any of the foregoing ICs, the IC further includes a first switching circuit system configured to selectively switch a data input source of an SDA signal provided to the auxiliary controller, and a second switching circuit system configured to selectively switch a clock input source of a serial clock (SCL) signal provided to the auxiliary controller. The data input source is selectively switchable between an on-chip data source and an off-chip data source, and the clock input source is selectively switchable between an on-chip clock and an off-chip clock.

[0061] In another example IC of any of the foregoing ICs, the control logic of the deadlock resolver is further executable to drive the on-chip clock and the on-chip data source to transmit a signal pattern that simulates a transaction from the primary controller when the on-chip data source is selected as the data input source for the SDA signal and when the on-chip clock is selected as the clock input source for the SCL signal.

[0062] In another example IC of any of the foregoing ICs, the control logic of the deadlock resolver is further capable of executing to: select an off-chip data source as a data input source for an SDA signal provided to the auxiliary controller after transmitting a signal pattern; monitor an external signal issued by an off-chip clock and an off-chip data source; and select the off-chip clock as a clock input source for an SCL signal provided to the auxiliary controller based at least in part on detecting a start signature of a predetermined event type in the external signal.

[0063] In another example IC of any of the foregoing ICs, the primary controller and the secondary controller are configured to communicate via an I3C protocol through the deadlock resolver.

[0064] In another example of any of the foregoing ICs, the predetermined event type includes a start condition. In another example of any of the foregoing ICs, the predetermined event type includes detecting a rising edge in a signal generated by an off-chip clock.

[0065] In yet another example IC of any of the foregoing ICs, the secondary controller is configured to monitor signals issued by an off-chip clock and an off-chip data source, and based at least in part on determining that the signals meet a bus idle condition, pull the SDA signal to a zero state and wait for the primary controller to assign a dynamic address to the secondary controller.

[0066] The method disclosed herein provides a method for detecting a reset event indicator on a secondary controller, the indicator indicating a reset event pattern to be executed on the secondary controller while the secondary controller is in a reset state. The method also provides for transmitting a signal pattern to the secondary controller that simulates a transaction from a primary controller. The transmission is based at least in part on the detection of the reset event indicator, and the signal pattern is effective to assist the secondary controller in exiting the reset state.

[0067] In another example method of any of the foregoing methods, the signal pattern is transmitted from the deadlock resolver to the secondary controller, and the deadlock resolver provides a communication interface between the secondary controller and the primary controller.

[0068] In another example method of any of the foregoing methods, the deadlock resolver further includes a first switching circuit system and a second switching circuit system, the first switching circuit system being configured to selectively switch a data input source of an SDA signal received at the auxiliary controller, and the second switching circuit system being configured to selectively switch a clock input source of a serial clock (SCL) signal received at the auxiliary controller. The data input source is selectively switchable between an on-chip data source and an off-chip data source, and the clock input source is selectively switchable between an on-chip clock and an off-chip clock.

[0069] In another example method of any of the foregoing methods, the transmission signal mode further includes: when the on-chip data source is selected as the input source of the SDA signal and when the on-chip clock is selected as the input source of the SCL signal, driving the on-chip clock and the on-chip data source to transmit the signal mode.

[0070] In another example method of any of the foregoing methods, the method further includes: after transmitting the signal pattern, selecting an off-chip data source as a data input source for the SDA signal provided to the auxiliary controller; monitoring an external signal emitted by the off-chip clock and the off-chip data source; and selecting the off-chip clock as a clock input source for the SCL signal provided to the auxiliary controller based at least in part on detecting a start signature of a predetermined event type in the external signal.

[0071] In a further example method of any of the foregoing methods, the primary controller and the secondary controller are configured to communicate via an I3C protocol.

[0072] In a further example method of any of the foregoing methods, detecting a start signature of the predetermined event type includes detecting a start condition or detecting a rising edge in the SCL signal.

[0073] In another example method of any of the foregoing methods, the method further includes monitoring, by the secondary controller, the SDA signal and the SCL signal, and based at least in part on determining that the SDA signal and the SCL signal satisfy a bus idle condition, pulling the SDA signal to a zero state and waiting for the primary controller to assign a dynamic address to the secondary controller.

[0074] The example system disclosed herein includes: a first switching circuit system configured to selectively switch the data input source of the SDA signal input to the auxiliary controller; and a second switching circuit system configured to selectively switch the clock input source of the serial clock (SCL) signal input to the auxiliary controller. The data input source can be selectively switched between an on-chip data source and an off-chip data source, while the clock input source can be selectively switched between an on-chip clock and an off-chip clock. The system also includes control logic that is executable to detect a reset event indicator on the auxiliary controller and, based at least in part on the detection of the reset event indicator, drives the on-chip clock and the on-chip data source to transmit a signal pattern when the on-chip data source is selected as the data input source for the SDA signal and when the on-chip clock is selected as the clock input source for the SCL signal. The signal pattern simulates a transaction from the primary controller, which effectively assists the auxiliary controller in exiting a reset state.

[0075] In another example system of any of the foregoing systems, the control logic is further capable of executing to: select an off-chip data source as a data input source for an SDA signal provided to the auxiliary controller after a transmission signal pattern; monitor an external signal emitted by an off-chip clock and an off-chip data source; and select the off-chip clock as a clock input source for an SCL signal provided to the auxiliary controller based at least in part on detecting a start signature of a predetermined event type in the external signal.

[0076] In another example system of any of the foregoing systems, the primary controller and the secondary controller are configured to communicate via an I3C protocol.

[0077] In another example system of any of the foregoing systems, detecting the predetermined event type includes detecting a start condition or detecting a rising edge in the SCL signal.

[0078] The example system disclosed herein includes means for detecting a reset event indicator on a secondary controller, the reset event indicator indicating a reset event pattern to be executed on the secondary controller when the secondary controller is in a reset state. The method further provides means for transmitting a signal pattern simulating a transaction from a primary controller to the secondary controller in response to detecting the reset event pattern. The signal pattern effectively assists the secondary controller in exiting the reset state.

[0079] The above description, examples, and data provide a complete description of the structure and use of the exemplary implementation. Since many implementations can be implemented without departing from the spirit and scope of the claimed invention, the appended claims define the present invention. In addition, the structural features of the different examples can be combined in another implementation without departing from the claims.

Claims

1. An integrated circuit (IC), comprising: A deadlock resolver providing a communication interface between the primary controller (110) and the secondary controller (218)(217)(128), the deadlock resolver storing control logic executable to: detecting a reset event indicator on the auxiliary controller (218) (217) (128), the reset event indicator indicating a reset event pattern to be executed on the auxiliary controller (218) (217) (128) when the auxiliary controller (218) (217) (128) is in a reset state; and Based at least in part on detecting the reset event indicator, a signal pattern simulating a transaction from a primary controller (110) is transmitted to the secondary controller (218)(217)(128), the signal pattern assisting the secondary controller (218)(217)(128) in exiting a reset state.

2. The IC of claim 1 , further comprising: a first switching circuit system configured to selectively switch a data input source of an SDA signal provided to the auxiliary controller, the data input source being selectively switched between an on-chip data source and an off-chip data source; The second switching circuit system is configured to selectively switch a clock input source of a serial clock (SCL) signal provided to the auxiliary controller, the clock input source being selectively switched between an on-chip clock and an off-chip clock.

3. The IC of claim 2 , wherein the control logic of the deadlock resolver is further executable to: When the on-chip data source is selected as the data input source of the SDA signal and when the on-chip clock is selected as the clock input source of the SCL signal, the on-chip clock and the on-chip data source are driven to transmit the signal pattern simulating the transaction from the primary controller.

4. The IC of claim 2 , wherein the control logic of the deadlock resolver is further executable to: After transmitting the signal pattern, selecting the off-chip data source as the data input source of the SDA signal to the auxiliary controller; monitoring external signals generated by the off-chip clock and the off-chip data source; and The off-chip clock is selected as the clock input source for the SCL signal to the auxiliary controller based at least in part on detecting a start signature of a predefined event type in the external signal. 5 . The IC of claim 1 , wherein the primary controller and the secondary controller are configured to communicate through the deadlock resolver via an I 3 C protocol. The IC of claim 4 , wherein the predefined event type comprises a start condition.

7. The IC of claim 4, wherein the predefined event type comprises detecting a rising edge in a signal generated by the off-chip clock.

8. The IC of claim 2, wherein the auxiliary controller is configured to: Based at least in part on exiting the reset state, monitoring signals issued by the off-chip clock and the off-chip data source; and Based at least in part on determining that the signal satisfies a bus idle condition, pulling the SDA signal to a zero state and waiting for the primary controller to assign a dynamic address to the secondary controller.

9. A method comprising: detecting a reset event indicator on an auxiliary controller (218) (217) (128), the reset event indicator indicating a reset event pattern to be executed on the auxiliary controller (218) (217) (128) when the auxiliary controller (218) (217) (128) is in a reset state; and Based at least in part on detecting the reset event indicator, transmitting to the secondary controller (218)(217)(128) a signal pattern simulating a transaction from the primary controller (110), the signal pattern effective to assist the secondary controller (218)(217)(128) in exiting the reset state.

10. The method of claim 9, wherein the signal pattern is transmitted to the secondary controller from a deadlock resolver, the deadlock resolver providing a communication interface between the secondary controller and a primary controller.

11. The method of claim 10, wherein the deadlock resolver further comprises: a first switching circuit system configured to selectively switch a data input source of an SDA signal received at the auxiliary controller, the data input source being selectively switched between an on-chip data source and an off-chip data source; as well as The second switching circuit system is configured to selectively switch a clock input source of a serial clock (SCL) signal received at the auxiliary controller, the clock input source being selectively switched between an on-chip clock and an off-chip clock.

12. The method of claim 11, wherein transmitting the signal pattern further comprises: When the on-chip data source is selected as the input source of the SDA signal and when the on-chip clock is selected as the input source of the SCL signal, the on-chip clock and the on-chip data source are driven to transmit the signal pattern.

13. The method according to claim 11, further comprising: After transmitting the signal pattern, selecting the off-chip data source as the data input source of the SDA signal to the auxiliary controller; monitoring external signals emitted by the off-chip clock and the off-chip data source; as well as The off-chip clock is selected as the clock input source for the SCL signal to the auxiliary controller based at least in part on detecting a start signature of a predefined event type in the external signal.

14. The method of claim 9, wherein the primary controller and the secondary controller are configured to communicate via an I3C protocol.

15. The method of claim 13, wherein detecting the start signature of the predefined event type comprises detecting a start condition or detecting a rising edge in the SCL signal.

16. The method according to claim 13, further comprising: The auxiliary controller monitors the SDA signal and the SCL signal; Based at least in part on determining that the SDA signal and the SCL signal satisfy a bus idle condition, pulling the SDA signal to a zero state and waiting for a primary controller to assign a dynamic address to the secondary controller.

17. A system (200), comprising: A first switching circuit system is configured to selectively switch a data input source of an SDA (130) signal (220) (138) input to an auxiliary controller (218) (217) (128), wherein the data input source is selectively switched between an on-chip data source and an off-chip data source. a second switching circuit system configured to selectively switch a clock input source of a serial clock (SCL) signal input to the auxiliary controller (218)(217)(128), the clock input source being selectively switched between an on-chip clock and an off-chip clock; as well as Control logic executable to detect a reset event indicator on the auxiliary controller (218)(217)(128), and based at least in part on detecting the reset event indicator: When the on-chip data source is selected as the data input source of the SDA (130) signal (220) (138) and when the on-chip clock is selected as the clock input source of the SCL signal (222) (140), the on-chip clock and the on-chip data source are driven to transmit a signal pattern that simulates a transaction from a primary controller (110) and effectively assists the secondary controller (218) (217) (128) to exit a reset state.

18. The system of claim 17, wherein the control logic is further executable to: After transmitting the signal pattern, selecting the off-chip data source as the data input source of the SDA signal to the auxiliary controller; monitoring external signals generated by the off-chip clock and the off-chip data source; and The off-chip clock is selected as the clock input source for the SCL signal to the auxiliary controller based at least in part on detecting a start signature of a predefined event type in the external signal.

19. The system of claim 17, wherein the primary controller and the secondary controller are configured to communicate via an I3C protocol.

20. The system of claim 18, wherein detecting the predefined event type comprises detecting a start condition or detecting a rising edge in the SCL signal.

Images