Coexistence event detection and processing

Abstract

To provide a method, device, and non-transitory computer-readable media that enable simultaneous operation of various SoC components.SOLUTION: A system includes an electronic device having a SoC, and a coexistence coordinator coupled to the SoC and coupled to a coexistence controller implemented on the SoC. The coexistence controller detects occurrence of a coexistence event of SoC components, provides an indication of the occurrence of the coexistence event to the coexistence coordinator, and changes an operating point of the SoC from the current operating point to a new operating point in response to receiving an operating point change request from the coexistence coordinator.SELECTED DRAWING: Figure 5

Description

Technical Field

[0001] According to an example of the present disclosure, a method includes detecting, by a coexistence controller of a system-on-chip (SoC), an occurrence of a coexistence event of SoC components; providing, by the coexistence controller, an indication of the occurrence of the coexistence event to a coexistence coordinator; and changing, in response to receiving a request for changing an operating point from the coexistence coordinator, an operating point of the SoC from a current operating point to a new operating point.

[0002] According to another example of the present disclosure, a device includes a system-on-chip (SoC) having at least one SoC component. The device also includes a coexistence controller coupled to the SoC. The coexistence controller is configured to detect an occurrence of a coexistence event of SoC components, provide an indication of the occurrence of the coexistence event to a coexistence coordinator, and change an operating point of the SoC from a current operating point to a new operating point in response to receiving a request for changing an operating point from the coexistence coordinator.

[0003] According to yet another example of the present disclosure, a non-transitory computer-readable medium includes instructions that, when executed by a processor, cause the processor to detect an occurrence of a coexistence event of system-on-chip (SoC) components, provide an indication of the occurrence of the coexistence event to a coexistence coordinator, and change an operating point of the SoC from a current operating point to a new operating point in response to receiving a request for changing an operating point from the coexistence coordinator.

Brief Description of the Drawings

[0004] For a detailed description of various examples, reference is now made to the accompanying drawings.

[0005] [Figure 1] FIG. is a block diagram of a system for detecting and processing coexistence events according to various examples.

[0006] [Figure 2] This is a timing diagram of configuration functions implemented by coexistence coordinators and coexistence controllers, according to various examples.

[0007] [Figure 3] This is a timing diagram of monitoring or coexistence event detection functions implemented by coexistence controllers, according to various examples.

[0008] [Figure 4] This is a timing diagram of queries and coexistence actions implemented by coexistence coordinators and coexistence controllers, according to various examples.

[0009] [Figure 5] This is a flowchart of methods for detecting and handling coexisting events, following various examples. [Modes for carrying out the invention]

[0010] Electronic devices are often designed to provide increasingly large amounts of functionality using a reduced number of integrated circuits. Examples of such electronic devices include smartphones and Internet of Things (IoT) devices. In some cases, electronic devices include a system-on-a-chip (SoC), where many of the electronic device's components are integrated onto a single integrated circuit (IC). These components may include a central processing unit (CPU), memory (e.g., built into or integrated in the SoC, or external memory accessed via a memory interface), general-purpose input / output (GPIO) interfaces, radio frequency (RF) interfaces, analog interfaces (e.g., analog-to-digital converters (ADCs)), wired interfaces (e.g., universal asynchronous receiver-transmitter (UART), serial peripheral interface (SPI), universal serial bus (USB)), power and clock control interfaces, various sensor interfaces (e.g., environmental sensors), and other interfaces. RF interfaces provide the ability to communicate using one or more wireless protocols (e.g., cellular, Wi-Fi, Bluetooth®, Bluetooth Low Energy (BLE)). The aforementioned components or interfaces that enable communication between the various components of an SoC are generally referred to as SoC components.

[0011] Due in part to the nature of integration in an SoC (or other ICs in an electronic device), coexistence issues can arise between various SoC components (particularly those integrated into and / or controlled by the SoC) and / or functions provided by the SoC. For example, a performance trade-off may exist between a first and second component of an SoC, where increasing the performance or operational capability of the first SoC component may adversely affect the performance or operational capability of the second SoC component. In some cases, the activity of the first SoC component may degrade the performance of the second SoC component, or even prevent simultaneous activity of the second SoC component. As one specific example, an SoC may be able to maximize or provide relatively high output power for an RF SoC component (e.g., BLE) while failing to maximize or provide a relatively high sampling rate for an ADC SoC component.

[0012] An SoC-level operating point refers to a combination of simultaneous performance or operating capabilities of multiple SoC components (e.g., a set of SoC component-specific operating profiles or parameter configurations) that also satisfy limiting factors such as the total power consumption level of the SoC, the thermal rise of the SoC (e.g., relative to the baseline temperature), or the lifetime of the SoC (e.g., the ability to maintain a specific performance level over time). For example, as described above, in some cases, multiple SoC components cannot operate simultaneously at each of their highest performance or operating capabilities. Therefore, an example of a first operating point includes a first SoC component (e.g., BLE) operating at a relatively high performance or operating capability (e.g., higher output power) and a second SoC component (e.g., ADC) operating at a relatively low performance or operating capability (e.g., reduced sampling rate) to satisfy the total power consumption level of the SoC (or other SoC limiting factors). An example of a second operating point includes a first SoC component operating at relatively low performance or capability, and a second SoC component operating at relatively high performance or capability while maintaining a similar total power consumption level for the SoC (e.g., satisfying SoC limiting factors).

[0013] A Key Performance Indicator (KPI) is a metric or value that quantifies the combined performance level of multiple SoC components of a device or SoC. In some cases, a particular KPI may be improved by selecting aggregated operating points at a specific SoC level (e.g., a set of operating points for some or all of the SoC components). Examples of operating KPIs include, among others, the response time of a particular SoC component, service availability (e.g., the amount of time it takes to complete a particular action), the accuracy of an action (e.g., ADC resolution or accuracy, RF transmit error rate, interface (e.g., UART) error rate), external memory read / write error probability, throughput, and power consumption (e.g., SoC-level power consumption, or power consumption of a particular SoC component).

[0014] In some cases, coexistence solutions are implemented between RF interfaces to enable the simultaneous operation of various SoC components, resulting in electronic devices being able to communicate using multiple wireless protocols simultaneously (or obviously simultaneously with the user). In these cases, the coexistence solution does not consider the interrelationships and impacts on the performance or operational capabilities of various other types of SoC components, such as those described above. Furthermore, despite the fact that users are affected, users of electronic devices are generally unaware of coexistence-related issues between SoC components (or their impact on device performance), and are unable to influence the electronic device (e.g., the operating point of the electronic device) to resolve such coexistence-related issues.

[0015] The examples described herein address the aforementioned by providing a coexistence controller as part of the SoC. The coexistence controller may be implemented as hardware of the SoC (e.g., an application-specific integrated circuit (ASIC) of the SoC), as software executed by the SoC, or as a combination of hardware and software. The coexistence controller is configured to detect the occurrence of coexistence events. A coexistence event is an event or action that affects, influences, or otherwise alters (or causes a deviation from the SoC's operating point) the operating point of the SoC (e.g., causes a modification to the operating point of another SoC component). An example of a coexistence event is an operating metric of at least one SoC component that indicates a relative performance degradation (e.g., below or above a threshold) relative to the current SoC operating point. Another example of a coexistence event is the occurrence of an action (e.g., a user action) that can be improved by modifying the SoC operating point or by one or more SoC components configured to provide additional performance capabilities beyond what is permissible by the current SoC operating point. For example, a coexistence event occurs after repeated use of the ADC (e.g., exceeding a threshold amount), while the current operating point prioritizes improving the performance of another SoC component, thus degrading ADC performance. In another example, a coexistence event occurs in response to the number of accesses or uses of shared hardware components (e.g., memory, microcontroller units (MCUs), hardware accelerators) by different processes of the SoC exceeding a threshold amount. In yet another example, a coexistence event occurs in response to the number of accesses or uses of a shared wired interface by different processes of the SoC exceeding a threshold amount.

[0016] The coexistence controller is configured to provide instructions to the coexistence coordinator regarding the occurrence of coexistence events. The coexistence coordinator can be located on an electronic device, such as software running on the SoC, or it can be located remotely to an electronic device, such as in a cloud-based application. In one example, the coexistence coordinator is configured to provide instructions to a user (e.g., on the GUI (graphical user interface) of an electronic device including the SoC) regarding the occurrence of a coexistence event and to receive user input for coexistence actions to address the coexistence event, such as changing the operating point of the electronic device (e.g., transitioning from the current operating point to a new operating point). For example, user input may cause the device to transition to an operating point that supports the use of the SoC component that triggered the coexistence event (e.g., increased ADC usage). Coexistence actions (e.g., changes in operating points) can reduce the power consumption of a particular component, improve the throughput of a particular SoC component, improve the latency response of a particular component, and / or increase the utilization efficiency of other SoC resources.

[0017] Therefore, the user can dynamically change the operating point of an electronic device in response to the occurrence of a coexistence event, for example, to mitigate the occurrence of similar coexistence events in the future. Continuing the above example where the action and / or device usage demonstrates an increased demand for ADC performance, the coexistence coordinator is configured to indicate to the user that the current demand for ADC performance exceeds what is permitted by the current operating point. The user can then select a new operating point that increases ADC performance. In some cases, the new operating point may reduce the performance of another SoC component to enable improved ADC performance while still satisfying the aforementioned limiting factors.

[0018] In response to the user selecting a new operating point, the coexistence coordinator provides instructions for the user selection to the coexistence controller, which in turn alters the performance or operating characteristics of the SoC components associated with the change from the current operating point to the new operating point.

[0019] Various application programming interfaces (APIs) are provided between the coexistence coordinator, the coexistence controller, and the controlled SoC components that enable the aforementioned functions.

[0020] In some examples, the coexistence controller is also configured to receive queries (e.g., from the coexistence coordinator). These queries involve potential changes to the operating points of the SoCs. The coexistence controller is configured to determine the impact of potential operating point changes on the coexistence of two or more SoC components and to provide the coexistence coordinator with instructions on the impact.

[0021] This allows users of electronic devices to recognize the potential impact of changes in operating points before deciding to make changes to the electronic device. For example, a user might want to improve the battery performance of an electronic device, which would negatively impact the performance or operational capability of one or more SoC components (e.g., reducing BLE output power, reducing the ADC sampling rate). In response to a user query regarding increased battery performance of an electronic device, the coexistence controller determines that the BLE output power needs to be reduced and / or the ADC sampling rate needs to be reduced, and provides instructions on these impacts to the user via the coexistence coordinator.

[0022] Figure 1 is a block diagram of a system 100 according to the example described herein. The system 100 includes an electronic device 101 having a SoC 102, and the SoC 102 includes a coexistence controller 104. The system 100 also includes a coexistence coordinator 106 coupled to the SoC 102, and particularly, coupled to the coexistence controller 104 implemented on the SoC 102.

[0023] The SoC 102 also includes peripheral components 108 and a resource component 110 that schematically represents the various SoC components described above. For example, the peripheral components 108 include a peripheral connectivity and / or information acquisition interface, or a processing accelerator interface. Continuing with this example, the resource component 110 includes controllers such as a memory controller, a power controller, and an access controller. The specific peripheral components 108 and resource components 110 described above are illustrative. For example, the SoC 102 may include additional components other than those described above, and the SoC 102 does not necessarily include all of the components described above.

[0024] In one example, the coexistence controller 104 is implemented as hardware of the SoC 102 by, for example, an ASIC of the SoC 102. In another example, the coexistence controller 104 is implemented as software executed by the SoC 102 (e.g., by a processor of the SoC 102). In yet another example, the coexistence controller 104 is implemented as a combination of the hardware of the SoC 102 and the software executed by the SoC 102. In some examples, the coexistence coordinator 106 may be located on the electronic device 101 including the SoC 102 and implemented as software executed by the SoC 102 and / or as hardware of the SoC 102. In other examples, the coexistence coordinator 106 is located remotely from the electronic device 101 including the SoC 102, such as being implemented as a cloud-based application or other application with which the electronic device 101 communicates.

[0025] Regardless of the specific implementation of coexistence controller 104 and coexistence coordinator 106, coexistence controller 104 and coexistence coordinator 106 are configured to communicate using various APIs. These APIs enable requests (e.g., queries), responses, event indications, commands, and other types of communication between coexistence controller 104 and coexistence coordinator 106.

[0026] Coexistence controller 104 is configured to detect the occurrence of coexistence events. As described above, a coexistence event is an event or action that affects, impacts, or otherwise changes an operating point of SoC 102. The SoC 102 operating point is a combination of the simultaneous performance or operating capabilities of multiple SoC 102 components, such as peripheral component 108 and / or resource component 110. The operating point of SoC 102 satisfies limiting factors such as the total power consumption of SoC 102, the heat rise of SoC 102, or the lifespan or capabilities that maintain the performance level of SoC 102 over time.

[0027] In one example, the BLE component of SoC 102 and the ADC component of SoC 102 are referenced. The BLE component and the ADC component are examples of peripheral component 108. In this example, the operating capability of the BLE component is an output power value, where a larger output power represents a greater operating capability of the BLE component and a smaller output power represents a smaller operating capability of the BLE component. Continuing with this example, the operating capability of the ADC component is a sampling rate value, where a larger sampling rate represents a greater operating capability of the ADC component and a smaller sampling rate represents a smaller operating capability of the ADC component. In this example, the limiting factor for the operating point is the power consumption level of SoC 102.

[0028] At the first example operating point, the output power of the BLE component is a first value, the sampling rate of the ADC is a second value, while the power consumption of the SoC102 is a third value or less. Since the power consumption of the SoC102 is a limiting factor for the operating point, it may be impossible to increase the output power of the BLE component to above the first value while maintaining the ADC sampling rate at the second value. Similarly, it may be impossible to increase the ADC sampling rate to a value greater than the second value while maintaining the output power of the BLE component at the first value. Therefore, the "trade-off" between the operating capabilities of the BLE component and the ADC component is useful for achieving different operating points.

[0029] At the second example operating point, the output power of the BLE component is a fourth value greater than the first value, while the sampling rate of the ADC is a fifth value less than the second value. The second operating point satisfies the limiting factor that the power consumption of the SoC102 is the third value or less.

[0030] At the third example operating point, the output power of the BLE component is a sixth value, which is less than the first value, while the sampling rate of the ADC is a seventh value, which is greater than the second value. The third operating point also satisfies the limitation that the power consumption of the SoC102 is at or less than the third value. The second and third operating points demonstrate a trade-off between the operating capabilities of the BLE component and the ADC component, while still satisfying the limitation that the power consumption of the SoC102 is at or less than the third value.

[0031] In one example, a coexistence event occurs when the output power of a BLE component is less than the expected value for a given operating point. This indicates that a coexistence problem can occur because the BLE component's performance is inferior to the expected operating capability for a given operating point. For example, a coexistence event occurs at the first operating point when the output power of the BLE component is less than the first value. A coexistence event occurs at the second operating point when the output power of the BLE component is less than the fourth value. A coexistence event occurs at the third operating point when the output power of the BLE component is less than the sixth value.

[0032] Similarly, a coexistence event occurs when the sampling rate of an ADC component is less than the expected value for a given operating point, indicating that the ADC component is underperforming compared to its expected operating capability for a given operating point, and thus a coexistence problem can occur. For example, a coexistence event occurs when the sampling rate of an ADC component is less than the second value at the first operating point. A coexistence event occurs when the sampling rate of an ADC component is less than the fifth value at the second operating point. A coexistence event occurs when the sampling rate of an ADC component is less than the seventh value at the third operating point.

[0033] Regardless of which of the specific scenarios described above causes the coexistence event, the occurrence of such a coexistence event indicates that one of the components of the SoC102 (e.g., the BLE component and / or the ADC component, or peripheral components 108 such as the resource component 110) is underperforming, which may be in response to a coexistence problem with another component of the SoC102. As will be described later, the coexistence controller 104 is configured to change the operating point of the SoC102 from its current operating point to a new operating point in response to receiving an operating point change request from the coexistence coordinator 106, etc.

[0034] In one example, changing the operating point of SoC102 to a new operating point may improve the performance of an SoC102 component whose poor performance led to the occurrence of a coexistence event. For example, in the case of a coexistence event that occurred in response to the output power of a BLE component being less than the expected value for the current operating point, the new operating point may increase the output power of the BLE component (for example, the current operating point is the first operating point and the new operating point is the second operating point). If a coexistence event occurred in response to the sampling rate of an ADC component being smaller than the expected value for the current operating point, the new operating point may increase the sampling rate for the ADC component (for example, the current operating point is the first operating point and the new operating point is the third operating point). Therefore, the coexistence controller 104 that changes the operating point of SoC102 to a new operating point can improve the performance of the underperforming SoC102 component.

[0035] Coexistence events also occur when an action (e.g., a user action) occurs that indicates a performance requirement for SoC102 components that is greater than what is available at the current operating point of SoC102. In this example, a coexistence event occurs when the demand for output power of a BLE component (e.g., from a user action or application performed by SoC102) is greater than the value provided by a given operating point, indicating that a coexistence problem can occur because the demand for the BLE component is greater than the operating capability at a given operating point. Demand from user actions or applications can also be indicated by the number of repeated or attempted uses (e.g., per unit time) that is greater than a threshold.

[0036] For example, a coexistence event occurs when the demand for BLE output power at the first operating point is greater than a first value. A coexistence event occurs when the demand for BLE output power at the second operating point is greater than a fourth value. A coexistence event occurs when the demand for BLE output power at the third operating point is greater than a sixth value. Coexistence events can also occur in response to repeated or attempted use (e.g., per unit time) of BLE components being greater than a threshold.

[0037] Similarly, a coexistence event occurs when the demand for the ADC sampling rate (e.g., from user actions or applications performed by the SoC102) is greater than the value provided by a given operating point, indicating that the demand for the ADC components is greater than the operating capacity at a given operating point, thus a coexistence problem can occur. Demand from user actions or applications can also be indicated by the number of repeated or attempted uses (e.g., per unit time) that is greater than a threshold.

[0038] For example, a coexistence event occurs when the demand for the ADC sampling rate at the first operating point is greater than the second value. A coexistence event occurs when the demand for the ADC sampling rate at the second operating point is greater than the fifth value. A coexistence event occurs when the demand for the ADC sampling rate at the third operating point is greater than the seventh value. Coexistence events can also occur in response to repeated or attempted use (e.g., per unit time) of the ADC components being greater than a threshold.

[0039] Regardless of which of the specific scenarios described above triggers the coexistence event, the occurrence of such a coexistence event indicates that one of the components of the SoC102 (e.g., the BLE component and / or the ADC component, or peripheral components 108 such as the resource component 110) is not performing adequately to user-based or application-based requirements. As will be described later, the coexistence controller 104 is configured to change the operating point of the SoC102 from its current operating point to a new operating point in response to receiving an operating point change request from the coexistence coordinator 106.

[0040] In one example, changing the SoC102 to a new operating point may improve the performance of an SoC102 component that is experiencing a higher-than-expected demand (e.g., relative to the current operating point) that leads to a coexistence event. For example, in the case of a coexistence event that occurs in response to a demand for BLE output power being greater than the expected value for the current operating point, the new operating point may provide a higher output power to the BLE component (e.g., the current operating point is the first operating point and the new operating point is the second operating point). In the case of a coexistence event that occurs in response to a demand for ADC sampling rate being greater than the expected value for the current operating point, the new operating point may provide a higher sampling rate to the ADC component (e.g., the current operating point is the first operating point and the new operating point is the third operating point). Thus, the coexistence controller 104 can improve the performance of an underperforming SoC102 component by changing the SoC102's operating point to a new operating point.

[0041] Figure 2 is a timing diagram 200 illustrating the configuration functions implemented by the coexistence coordinator 106 (or its event control engine 112) and the coexistence controller 104. The configuration functions enable the coexistence coordinator 106 to define specific criteria for the coexistence controller 104 to detect coexistence events.

[0042] For example, in block 202, the coexistence coordinator 106 determines to configure the coexistence controller 104 to detect coexistence events in response to the occurrence of a specific criterion. In some examples, the coexistence coordinator 106 determines to configure the coexistence controller 104 in response to receiving an instruction that the electronic device 101 is in a powered-on state (e.g., powered on or woken up from standby).

[0043] In block 204, the event control engine 112 of the coexistence coordinator 106 sends a request or message to the coexistence controller 104. The request or message includes specific criteria for the coexistence controller 104 to detect a coexistence event. In response to receiving the request or message in block 206, the coexistence controller 104 is configured to begin monitoring the peripheral components 108 and / or resource components 110 according to the identified coexistence event criteria.

[0044] In one example, the criteria for determining the occurrence of a coexistence event include an activity (e.g., a function implemented by peripheral component 108 and / or resource component 110) that is below a specified threshold, or the throughput of an activity that does not meet a minimum throughput target value. Therefore, a coexistence event occurs in response to the activity throughput being below the threshold or, in this example, not meeting the minimum target value. Thus, the coexistence controller 104 is configured to detect such coexistence events in this example.

[0045] In another example, the criteria for determining the occurrence of a coexistence event include the amount of time and / or power consumed by an activity that exceeds a specified threshold. In this example, a coexistence event occurs in response to an activity consuming more power than permitted by the threshold or completing for a longer period of time than permitted by the threshold. Therefore, the coexistence controller 104 is configured to detect such coexistence events in this example.

[0046] In yet another example, the criteria for determining the occurrence of a coexistence event include the activity start time being delayed by a threshold amount beyond the expected start time, or the activity having a latency greater than a threshold amount. In this example, the coexistence event occurs in response to the activity having a latency greater than permitted by the threshold. Therefore, the coexistence controller 104 is configured to detect such a coexistence event in this example.

[0047] In a further example, the criteria for determining the occurrence of a coexistence event include the fact that a request to initiate an activity has been rejected more times than a threshold number of times by the implementing peripheral component 108 and / or resource component 110. Thus, in this example, a coexistence event occurs in response to the request to initiate an activity being rejected more times than permitted by the threshold. Therefore, the coexistence controller 104 is configured to detect such a coexistence event in this example.

[0048] In yet another example, the criteria for determining the occurrence of a coexistence event include the fact that a system resource (e.g., one or more of the peripheral component 108 and / or resource component 110) is occupied for a duration greater than a threshold amount to implement an activity. Thus, in this example, a coexistence event occurs in response to the activity being implemented on the system resource for a duration longer than permitted by the threshold. Therefore, the coexistence controller 104 is configured to detect such a coexistence event in this example.

[0049] In some cases, the coexistence event criteria identified by the message in block 204 include one of the above criteria or a combination of the above criteria. For example, a coexistence event criterion may specify that a coexistence event occurs in response to both the first and second criteria being met, or in response to either the first or second criterion being met. Other such logical combinations of coexistence event criteria are also within the scope of this description.

[0050] Figure 3 is a timing diagram 300 illustrating the monitoring or coexistence event detection function implemented by the coexistence controller 104. The monitoring function enables the coexistence controller 104 to detect coexistence events, which then allows various actions to be taken in response to those coexistence events, such as modifying the operating point of the SoC 102 or mitigating coexistence issues between peripheral components 108 and / or resource components 110 of the SoC 102 in other ways.

[0051] Timing diagram 300 includes block 206 described above, where the coexistence controller 104 is configured to begin monitoring the peripheral component 108 and / or resource component 110 according to the coexistence event criteria identified by the event control engine 112 of the coexistence coordinator 106. Subsequently, in blocks 302 and 304, the coexistence controller 104 receives status messages from the peripheral component 108 and / or resource component 110, respectively. The status messages indicate various parameters related to the activities implemented by the peripheral component 108 and / or resource component 110. For example, a BLE peripheral component 108 status message may include an indication of the output power parameter of the BLE peripheral component 108. As another example, an ADC peripheral component 108 status message may include an indication of the sampling rate parameter of the ADC peripheral component 108.

[0052] In block 306, the coexistence controller 104 analyzes the status messages provided in blocks 302 and 304. For example, the coexistence controller 104 compares the parameter values ​​indicated in the status messages with thresholds identified by the coexistence event criteria. As shown in Figure 3, the peripheral components 108 and resource components 110 continue to send status messages to the coexistence controller 104, which then continues to analyze the provided status messages.

[0053] In block 308, the coexistence controller 104 detects the occurrence of a coexistence event in response to one or more status messages and identified coexistence event criteria as described above. As described above, a coexistence event is an event or action that affects, influences, or otherwise modifies the operating point of the SoC 102. The SoC 102 operating point is a combination of the simultaneous performance or operating capabilities of multiple SoC 102 components, such as peripheral components 108 and / or resource components 110. The SoC 102 operating point can be identified by coexistence event criteria identified by the event control engine 112 of the coexistence coordinator 106, as described above. For example, a coexistence event criterion identifies a deviation from a desired SoC 102 operating point (e.g., throughput below a threshold, activity being delayed more than a threshold number of times, etc.). However, changing the SoC 102 operating point does not necessarily involve changing the coexistence event criteria. For example, the coexistence controller 104 detects an event in response to an activity having throughput below a threshold. In response, the coexistence coordinator 106 determines to change the SoC102 operating point, such as increasing the activity's priority or allocating more time to perform the activity, which improves the activity's throughput. However, the coexistence coordinator 106 does not reconfigure the event detection criteria of the coexistence controller 104, and therefore the coexistence controller 104 continues to monitor the activity throughput against a previously used throughput threshold. In another example, in response to a change in the SoC102 operating point, the coexistence coordinator 106 reconfigures the event detection criteria of the coexistence controller 104. For example, the reconfigured event detection criteria may include monitoring other activities that may be affected by the increased priority given to the activity that caused the coexistence event (e.g., activities whose throughput was below a threshold). As described above, the SoC102 operating point satisfies limiting factors such as the total power consumption of the SoC102, the thermal rise of the SoC102, or the lifetime or ability to maintain the SoC102's performance level over time.

[0054] In one example, the BLE peripheral component 108 and the ADC peripheral component 108 are referenced. In this example, the operating capability of the BLE peripheral component 108 is the output power value, where a higher output power represents a higher operating capability of the BLE peripheral component 108, and a lower output power represents a lower operating capability of the BLE peripheral component 108. Continuing this example, the operating capability of the ADC peripheral component 108 is the sampling rate value, where a higher sampling rate represents a higher operating capability of the ADC peripheral component 108, and a lower sampling rate represents a lower operating capability of the ADC peripheral component 108. In this example, the limiting factor for the operating point is the power consumption level of the SoC 102.

[0055] In one example, the coexistence controller 104 detects a coexistence event in block 308 in response to a status message from the BLE peripheral component 108 indicating that the output power of the BLE peripheral component 108 is less than the expected value for a given operating point, which indicates that a coexistence problem may occur because the BLE peripheral component 108 is underperforming in terms of the expected operating capability at a given operating point. For example, a coexistence event occurs when the output power of the BLE peripheral component 108 is less than the threshold specified by the coexistence event criterion at a first operating point (which may be defined by the coexistence event criterion identified above).

[0056] Similarly, the coexistence controller 104 detects a coexistence event in block 308 in response to a status message from the ADC peripheral component 108 indicating that the sampling rate of the ADC peripheral component 108 is lower than the expected value for a given operating point. This indicates that a coexistence problem may occur because the ADC peripheral component 108 is underperforming in terms of its expected operating capability for a given operating point. For example, a coexistence event occurs when the sampling rate of the ADC peripheral component 108 is below a threshold specified by the coexistence event criterion at the first operating point.

[0057] Regardless of the type of coexistence event detected in block 308, in block 310, the coexistence controller 104 provides the coexistence coordinator 106 with instructions for the occurrence of the coexistence event. Specifically, the state control engine 114 of the coexistence coordinator 106 receives the instructions for the occurrence of the coexistence event and determines the action to be taken in response to the coexistence event. The state control engine 114 is also configured to receive state messages indicating various parameters related to the activities implemented by the peripheral components 108 and / or resource components 110. For example, a BLE peripheral component 108 state message may include instructions for the output power parameter of the BLE peripheral component 108. As another example, an ADC peripheral component 108 state message may include instructions for the sampling rate parameter of the ADC peripheral component 108. In yet another example, the state control engine 114 is configured to receive occasional (e.g., periodic) state API messages indicating, for example, the average throughput of one or more activities per unit time (e.g., one minute), the average power consumption of one or more activities per unit time, or the number of times an activity was rejected or delayed per unit time.

[0058] Figure 4 is a timing diagram 400 illustrating the query and coexistence action functions implemented by the coexistence coordinator 106 and the coexistence controller 104. The query and coexistence action functions respond to the occurrence of coexistence events, such as the coexistence events detected and indicated as described above.

[0059] Timing diagram 400 includes block 310 described above, where the coexistence controller 104 provides the coexistence coordinator 106 with instructions for the occurrence of a coexistence event. Subsequently, in block 402, in response to the instructions for the occurrence of a coexistence event, the coexistence coordinator 106 is configured to provide a query to the coexistence controller 104. The query function can be implemented by the query engine 116 of the coexistence coordinator 106. The query function allows the query engine 116 to determine the results of performing a particular coexistence action. For example, if the throughput of a first activity is below a threshold set by the coexistence event criteria described above, the query engine 116 may be configured to issue a query to determine the impact (e.g., the expected throughput of the first activity or the impact on the throughput of the second activity) in response to an increase in the priority of the first activity. In block 404, the coexistence controller 104 receives the query and provides a response to the coexistence coordinator 106.

[0060] In some cases, the query engine 116 may be configured in block 404 to issue additional queries following the response from the coexistence controller 104. Some other possible examples of queries include determining the impact on the power consumption of the electronic device 101 / SoC 102 in response to an increase in activity throughput; determining the impact on the latency of an activity in response to an increase in the priority of that activity; determining the impact on SoC 102 resource usage in response to a change in the throughput and / or latency requirements of a particular activity; determining the average power consumption in response to a decrease in output power, required throughput, or resource usage of a particular activity; and determining the impact on SoC 102 performance in response to a decrease in resource usage of a particular activity. Regardless of the specific content of the query, the coexistence controller 104 is configured to provide a response to such a query in order to enable the coexistence coordinator 106 to better notify subsequent coexistence decisions. In some examples, the coexistence coordinator 106 is configured to provide the user with the results of such queries, for example, on the GUI 130 of the electronic device 101. The coexistence coordinator 106 may also be configured to receive user input for performing a series of coexistence actions, such as implementing one of several proposed coexistence actions provided by the coexistence coordinator 106 (for example, on the GUI 130) in response to the occurrence of a coexistence event.

[0061] In block 406, the coexistence action engine 118 of the coexistence coordinator 106 is configured to request a change to the operating point of the SoC 102 (e.g., an operating point change request). As described above, in one example, the coexistence action engine 118 receives user input (e.g., confirmation of one of several proposed coexistence actions) and provides an operating point change request in response to the user input. In another example, the coexistence action engine 118 automatically determines a coexistence action (e.g., without responding to user input) and provides an operating point change request in response to such determination. For example, the coexistence action engine 118 may be configured to determine that the current SoC 102 operating point does not meet the performance requirements of one or more peripheral components 108 and / or resource components 110 of the SoC 102, and that a new SoC 102 operating point that better meets the performance requirements is available.

[0062] Regardless of how the coexistence operation engine 118 determines whether to provide an operation point change request, in block 408, the coexistence controller 104 receives the operation point change request and changes the operation point of the SoC 102. In block 410, the coexistence controller 104 causes the peripheral components 108 to modify at least one operational metric. For example, the coexistence controller 104 may be configured to cause the BLE peripheral component 108 to reduce (or increase) its output power, or the ADC peripheral component 108 to reduce (or increase) its sampling rate. In block 412, the coexistence controller 104 causes the resource components 110 to modify at least one operational metric. For example, the coexistence controller 104 may be configured to cause components such as the peripheral components 108 to use more or fewer shared resource components 110, or to cause the shared resource components 110 to limit their activity. For example, the coexistence controller 104 may be configured to cause a BLE peripheral component 108 to reduce (or increase) the use of a shared antenna interface (e.g., a shared resource component 110). In another example, the coexistence controller 104 may be configured to cause a power management shared resource component 110 to reduce (or increase) the voltage level of the SoC 102. The coexistence controller 104 may also be configured to limit (e.g., reduce or increase) the memory budget resource component 110 available to a particular peripheral component 108. In yet another example, the coexistence controller 104 may be configured to cause a power management shared resource component 110 to stop or suppress the activity of one or more other peripheral components 108 and / or resource components 110 in response to exceeding an acceptable average power consumption. In one example, the coexistence controller 104 may also be configured to cause a temperature sensor shared resource component 110 to stop or suppress the activity of one or more other peripheral components 108 and / or resource components 110 in response to exceeding an acceptable temperature level.

[0063] Therefore, the user can gain further insight or awareness of coexistence-related issues between the peripheral components 108 and / or resource components 110 of the SoC 102 (or their impact on the performance of the electronic device 101 / SoC 102). For example, the results of various queries issued by the query engine 116 can be displayed on the GUI 130 of the electronic device 101 for the user to see. Also, in at least some examples, the user can dynamically change the operating point of the SoC 102 based on such insight or awareness, for example, by selecting a new operating point from a list of available options on the GUI 130 in response to the occurrence of a coexistence event detected by the coexistence controller 104.

[0064] As described above, users of the electronic device 101 can recognize the potential impact of changes to the operating point before deciding to make changes to the electronic device 101. For example, a user may want to improve the battery performance of the electronic device 101, which may adversely affect the performance or operating capability of one or more peripheral components 108 and / or resource components 110 (e.g., reduced BLE output power, reduced ADC sampling rate). In response to a user query (e.g., implemented by the query engine 116) regarding the increased battery performance of the electronic device 101, the coexistence controller 104 determines that the output power of the BLE peripheral component 108 needs to be reduced and / or the sampling rate of the ADC peripheral component 108 needs to be reduced, and provides instructions on these impacts to the user via the coexistence coordinator 106.

[0065] Figure 5 is a flowchart of method 500 for detecting and processing coexistence events, according to the example described herein. Method 500 begins in block 502 by detecting the occurrence of coexistence events of components of SoC 102. As described above, the coexistence controller 104 is configured to detect coexistence events in response to coexistence event criteria (e.g., thresholds) provided by the coexistence coordinator 106. For example, the coexistence controller 104 can detect coexistence events in response to state indications provided by peripheral components 108 and / or resource components 110, and the relationship of those states to coexistence event criteria or thresholds.

[0066] Method 500 then continues in block 504 by providing the coexistence coordinator with an instruction that a coexistence event has occurred. As described above, the coexistence controller 104 is configured to provide such an instruction to the coexistence coordinator 106 in response to detecting a coexistence event, thereby enabling the coexistence coordinator 106 to determine an appropriate coexistence action (for example, automatically or in response to user input) to deal with or mitigate the coexistence event.

[0067] Method 500 continues in block 506 by changing the SoC's operating point from the current operating point to a new operating point in response to receiving an operating point change request. Specifically, the coexistence controller 104 is configured to cause the peripheral components 108 and / or resource components 110 to modify at least one operating metric in response to an operating point change request from the coexistence coordinator 106.

[0068] In some examples, Method 500 includes various other functions and processes described herein. Other examples described herein include non-temporary computer-readable media which, when executed by a processor (e.g., SoC 102), includes instructions that cause the processor to perform some or all of the processes of Method 500. For example, the coexistence controller 104 is implemented by a processor (e.g., SoC 102) that executes instructions on the computer-readable media to perform at least blocks 502, 504, and 506 of Method 500. Similarly, the coexistence coordinator 106 may be implemented by a processor (e.g., SoC 102 or another processor) that executes instructions on the computer-readable media to perform the functionality described herein as being attributable to the coexistence coordinator 106.

[0069] The term “to connect” is used throughout this description. This term may encompass any connection, communication, or signaling path that enables a functional relationship consistent with this description. For example, if device A generates a signal to control device B in order to perform a certain action, in the first example, device A is connected to device B, or in the second example, device A is connected to device B via intermediary component C, such that device B is controlled by device A via a control signal generated by device A, provided that intermediary component C does not substantially alter the functional relationship between device A and device B.

[0070] A device “configured” to perform a certain task or function may be configured (e.g., programmed and / or wired) by the manufacturer at the time of manufacture to perform that task or function, or may be configurable (or reconfigurable) by the user after manufacture to perform that function and / or other additional or alternative functions. Such configuration may be via the device’s firmware and / or software programming, via the configuration and / or layout of hardware components, via the interconnection of the devices, or a combination thereof.

[0071] Circuit elements or devices described herein as including specific components may instead be adapted to be coupled to those components to form the circuit or device described. For example, a structure described as including one or more semiconductor elements (such as transistors), one or more passive elements (such as resistors, capacitors, and / or inductors), and / or one or more sources (such as voltage and / or current sources) may instead include only semiconductor elements within a single physical device (e.g., a semiconductor die and / or integrated circuit (IC) package) and may be adapted to be coupled to at least some of the passive elements and / or sources to form the structure described, either during or after manufacturing, for example, by an end user and / or a third party.

[0072] Certain components may be described herein as belonging to a particular process technology, but these components may be substituted with components of other process technologies. The circuits described herein can be reconfigured to include the substituted components in order to provide functionality that is at least partially similar to the functionality available before the component substitution. Components indicated as resistors generally represent any one or more elements connected in series and / or parallel to provide the amount of impedance represented by the indicated resistor, unless otherwise specified. For example, a resistor or capacitor shown and described herein as a single component may instead be multiple resistors or capacitors, each connected in parallel between the same nodes. For example, a resistor or capacitor shown and described herein as a single component may instead be multiple resistors or capacitors, each connected in series between the same two nodes as a single resistor or capacitor.

[0073] Unless otherwise specified, the words "approximately," "about," or "substantially" preceding a value mean + / - 10% of the stated value.

Claims

1. 1. A method comprising: detecting, by a controller of a system-on-chip (SoC), a first deviation of a value of a first SoC component of the SoC from a first target value, the first SoC component including an analog-to-digital converter (ADC), the first target value being a target sampling rate such that detecting the first deviation includes detecting a first sampling rate of the ADC being below the target sampling rate; providing, by the controller, the first deviation to a coordinator; modifying, by the controller, an operating point of the second SoC component in response to receiving an operating point change request from the coordinator to reduce the first deviation, the second SoC component including a Bluetooth Low Energy (BLE) component, and modifying the operating point of the second SoC component includes reducing an output power of the BLE component; A method comprising:

2. 10. The method of claim 1, The method further comprising providing, by the controller, an indication of the new operating point of the second SoC component to the coordinator in response to changing the operating point of the second SoC component to a new operating point.

3. 10. The method of claim 1, The method, wherein an electrical device includes the SoC, and the operating point change request is in response to an input on a graphical user interface of the electronic device.

4. 10. The method of claim 1, receiving, by the controller, a query from the coordinator specifying a proposed operating point change for the SoC; determining an impact of the proposed operating point change on the first and second SoC components; providing an indication of the impact to the coordinator; The method further comprises:

5. 10. The method of claim 1, receiving, by the controller, a request for a coexistence status report from the coordinator, the request specifying a key performance indicator (KPI) for the first SoC component; providing, by the controller, the coexistence status report to the coordinator in response to the request, the coexistence status report including recommended operating point changes for the SoC to achieve the identified key performance indicators; The method further comprises:

6. The method of claim 1, The method further includes displaying an indication of the first deviation in a graphical user interface (GUI) of a device including the SoC.

7. The method of claim 1, receiving, by the controller, a first status message from the first SoC component; The method, wherein detecting the first deviation is based on the first status message.

8. The method according to claim 7, The method, wherein the first status message includes an output power value or a sampling rate value.

9. The method of claim 7, comprising: receiving periodic status messages from the first SoC component; The method, wherein the first status message is one of the periodic status messages.

10. The method of claim 1, receiving input via a graphical user interface (GUI) of a device including the SoC; The method, wherein the operating point change request is based on input received via the GUI.

11. The method of claim 1, The method, wherein altering the operating point of the second SoC component includes throttling the second SoC component.

12. The method of claim 4, The method, wherein the proposed operating point change for the SoC identified by the query comprises reducing battery usage of an electronic device that includes the SoC.

13. A method comprising: detecting, by a controller of a system-on-chip (SoC), a first deviation of a value of a Bluetooth Low Energy (BLE) component of the SoC from a first target value, the first target value being the target output power, such that detecting the first deviation includes detecting a first output power of the BLE component being below the target output power; providing, by the controller, the first deviation to a coordinator; changing, by the controller, an operating point of an analog-to-digital converter (ADC) of the SoC in response to receiving an operating point change request from the coordinator to reduce the first deviation, the changing including decreasing a sampling frequency of the ADC; A method comprising:

14. A device, a system-on-chip (SoC) including a first SoC component including a Bluetooth Low Energy (BLE) component and a second SoC component including an analog-to-digital converter (ADC); a controller coupled to the SoC, Detecting a first deviation of a value of the first SoC component from a first target value; providing the first deviation to a coordinator; changing an operating point of the second SoC component in response to receiving an operating point change request from the coordinator to reduce the first deviation. The controller configured to: Including, the first target value is the target output power, such that detecting the first deviation includes detecting a first output power of the BLE component being below the target output power; The device, wherein changing the operating point of the second SoC component includes decreasing the sampling frequency of the ADC.

15. 15. The device of claim 14, The device, wherein the controller is further configured to, in response to changing the operating point of the second SoC component to a new operating point, provide an indication of the new operating point of the second SoC component to the coordinator.

16. 15. The device of claim 14, further comprising a graphical user interface (GUI) coupled to the SoC; The device, wherein the operating point change request is responsive to an input on the GUI.

17. 15. The device of claim 14, The controller: receiving a query from the coordinator specifying a proposed operating point change for the SoC; determining an impact of the proposed operating point change on coexistence of the first and second SoC components; providing an indication of said impact to said coordinator; The device further configured as follows.

18. 15. The device of claim 14, The controller: receiving a request for a coexistence status report from the coordinator, the request identifying key performance indicators (KPIs) for the first SoC component; providing the coexistence state report to the coordinator in response to the request; further configured as follows: The device, wherein the coexistence status report includes a recommended operating point change for the SoC to achieve the specified KPI.

19. A non-transitory computer-readable medium, comprising: When executed by a processor, the processor: Detecting a first deviation of a value of a first system-on-chip (SoC) component of the SoC from a first target value; providing the first deviation to a coordinator; In response to receiving an operation point change request from the coordinator, changing an operation point of a second SoC component of the SoC from a current operation point to a new operation point. including instructions to the first SoC component includes a Bluetooth Low Energy (BLE) component and the second SoC component includes an analog-to-digital converter (ADC); the first target value is the target output power, such that detecting the first deviation includes detecting that a first output power of the BLE component is lower than the target output power; 4. The non-transitory computer-readable medium, wherein changing the operating point of the second SoC component includes decreasing a sampling frequency of the ADC.

20. 20. The non-transitory computer-readable medium of claim 19, A non-transitory computer-readable medium, wherein the instructions, when executed by the processor, further cause the processor to, in response to changing the operation point of the second SoC scheme element to a new operation point, provide an indication of the new operation point to the coordinator.

21. 20. The non-transitory computer-readable medium of claim 19, A non-transitory computer-readable medium, wherein an electrical device includes the SoC, and the operating point change request is in response to an input on a graphical user interface (GUI) associated with the electronic device.

22. 20. The non-transitory computer-readable medium of claim 19, The instructions, when executed by the processor, cause the processor to: receiving a query from the coordinator specifying a proposed operating point change for the SoC; determining an impact of the proposed operating point change on coexistence of the first and second SoC components; providing an indication of said impact to said coordinator; The non-transitory computer-readable medium further includes:

Images