System for link management between multiple communication chips

Abstract

A system for link management between a plurality of communication chips is disclosed. Embodiments relate to an integrated circuit of an electronic device that coordinates activity with another integrated circuit of the electronic device. The integrated circuit includes an interface circuit and a processor circuit. The interface circuit communicates over a multi-point bus connected to a plurality of electronic components. The processor circuit receives an authorization request from the integrated circuit via the interface circuit and the multipoint bus. The received authorization request is related to authorization to perform an activity on other integrated circuits. In response to receiving the authorization request, the processor circuit determines whether to authorize the other integrated circuit to perform the activity. In response to determining to authorize the other integrated circuit to perform the activity, the processor circuit sends an authorization signal to the other integrated circuit over the configurable direct connection to authorize the other integrated circuit to perform the activity.

Description

[0001] This application is a divisional application of Chinese invention patent application filed on December 8, 2020, with application number 2020800915714 and title "System for Link Management between Multiple Communication Chips". Technical Field

[0002] This disclosure relates to the coordinated operation of multiple integrated circuit (IC) chips in an electronic device. Background Technology

[0003] Electronic devices may include multiple Systems-on-a-Chip (SOCs) for communicating with other devices using various communication protocols. As the size of the communication systems in electronic devices decreases while their functionality increases, more SOCs are incorporated into the electronic devices, or more subsystems are added to each SOC. These SOCs can communicate with a host (e.g., a central processing unit or application processor) to transfer data via dedicated communication paths (e.g., Peripheral Component Rapid Interconnect (PCIe)).

[0004] As a result of integrating multiple communication systems and other subsystems into electronic devices, various problems or complexities may arise. These problems or complexities include conflicts in resource usage, interference in shared or overlapping communication bands, incompatible operating modes, isolation between antennas, and transmit power management between various concurrently operating systems (SOCs). In conventional electronic devices, such problems or complexities are typically addressed by coordinating the operation of the SOCs, and by having the central processing unit coordinate operations across multiple SOCs. Summary of the Invention

[0005] The implementation relates to an integrated circuit (e.g., a system-on-a-chip (SOC)) of an electronic device that coordinates activities with another integrated circuit (e.g., another SOC) within the same electronic device. The SOC includes interface circuitry and processor circuitry. The interface circuitry communicates via a multi-drop bus or point-to-point connection connected to one or more communication chips (e.g., SOCs) within the electronic device. The processor circuitry receives an authorization request from the other SOC via the interface circuitry and / or the multi-drop bus (or point-to-point connection), the authorization request seeking authorization to perform activities on the other SOC. In response to receiving the authorization request, the processor circuitry determines whether to authorize the other SOC to perform the activity. In response to determining that the other SOC is authorized to perform the activity, the processor circuitry sends an authorization signal to the other SOC via a configurable direct connection, authorizing the other SOC to perform the activity. Alternatively, the other SOC may be authorized to perform the activity on behalf of the first SOC. Attached Figure Description

[0006] Figure 1It is a high-level diagram of an electronic device according to an implementation plan.

[0007] Figure 2 This is a block diagram illustrating the components of an electronic device that communicates via a multipoint bus and a configurable direct connection according to one embodiment.

[0008] Figure 3 This is a block diagram illustrating a coexistence hub device according to one implementation scheme.

[0009] Figure 4 It is a block diagram of a system-on-a-chip (SOC) according to an implementation plan.

[0010] Figure 5 It is a block diagram illustrating the coordination of the operation of a pair of SOCs using a multipoint bus and configurable direct connections according to an implementation scheme.

[0011] Figure 6 This is an interactive diagram illustrating the operation and interaction of components in an electronic device according to one embodiment.

[0012] Figure 7 This is a timing diagram illustrating the coordination of components in an electronic device according to one embodiment.

[0013] Figure 8A It is a block diagram illustrating the use of a multipoint bus and configurable direct connections to coordinate the operation of a pair of SOCs for accessing resources according to an implementation scheme.

[0014] Figure 8B This illustrates a method from which an implementation plan is derived. Figure 8A The timing diagram for the coordination of the components.

[0015] Figure 9A It is a block diagram illustrating the use of a multipoint bus and configurable direct connections to coordinate the operation of a pair of SOCs for accessing shared (coexisting) resources according to an implementation scheme.

[0016] Figure 9B This illustrates a method from which an implementation plan is derived. Figure 9A The timing diagram for the coordination of the components.

[0017] Figure 10 This is a flowchart illustrating the process of coordinating the operation between components of an electronic device according to one embodiment.

[0018] For illustrative purposes only, the accompanying drawings and detailed descriptions depict various non-limiting embodiments. Detailed Implementation

[0019] Reference will now be made in detail to the embodiments, examples of which are shown in the accompanying drawings. Numerous specific details are shown in the following detailed description to provide a full understanding of the various described embodiments. However, the embodiments described may be implemented without these specific details. In other cases, well-known methods, processes, components, circuits, and networks are not described in detail so as not to unnecessarily obscure the various aspects of the embodiments.

[0020] The implementation scheme involves coordinating the operation of a subsystem within a communication system of an electronic device comprising a first integrated circuit (e.g., a first system-on-a-chip (SOC)) and a second integrated circuit (e.g., a second SOC or coexisting hub device) communicating with each other via a multipoint bus (or point-to-point connection) and a configurable direct connection. The second integrated circuit may receive an authorization request from the first integrated circuit via the multipoint bus, wherein the authorization request seeks authorization to perform activities on the first integrated circuit using one or more resources of the second integrated circuit. After the second integrated circuit determines whether to authorize the first integrated circuit to perform the activities, the second integrated circuit may send an authorization signal to the first integrated circuit via the configurable direct connection to authorize the first integrated circuit to perform the activities or a rejection signal to reject the first integrated circuit's attempt to perform the activities. In one or more implementations, the first integrated circuit continues with a hypothetical authorization for performing the activities. In such cases, the first integrated circuit may simply inform the second integrated circuit of the expected action of the first integrated circuit in the hypothetical implicit response of the second integrated circuit. In one or more other implementations, the first integrated circuit sends an authorization request seeking authorization to perform the activities to the second integrated circuit via a multipoint bus (or point-to-point connection), and the first integrated circuit may rely on the second integrated circuit to complete the activities when conditions permit.

[0021] Exemplary electronic devices This document describes implementations of electronic devices, user interfaces for such devices, and related processes for using such devices. In some implementations, the device is a portable communication device, such as a mobile phone, that also includes other functions such as a personal digital assistant (PDA) and / or music player functionality. Exemplary implementations of portable multi-functional devices include, but are not limited to, the iPhone from Apple Inc. (Cupertino, California). ® Devices, iPod Touch ® Devices, Apple Watch ® Devices and iPads ®Device. Alternatively, other portable electronic devices, such as wearable devices, laptops, or tablets, may be used. In some embodiments, the device is not a portable communication device, but a desktop computer or other computing device not designed for portable use. In some embodiments, the disclosed electronic device may include a touch-sensitive surface (e.g., a touchscreen display and / or touchpad). The following is combined with… Figure 1 The described example electronic device (e.g., device 100) may include a touch-sensitive surface for receiving user input. The electronic device may also include one or more other physical user interface devices, such as a physical keyboard, mouse, and / or joystick.

[0022] Figure 1 This is a high-level diagram of an electronic device 100 according to one embodiment. Device 100 may include one or more physical buttons, such as a "home" button or a menu button 104. Menu button 104 is used, for example, to navigate to any application in a set of applications running on device 100. In some embodiments, menu button 104 includes a fingerprint sensor for recognizing a fingerprint on menu button 104. The fingerprint sensor can be used to determine whether the finger on menu button 104 has a fingerprint that matches a fingerprint stored for unlocking device 100. Alternatively, in some embodiments, menu button 104 is implemented as a soft key in a graphical user interface (GUI) displayed on a touchscreen.

[0023] In some embodiments, device 100 includes a touchscreen 150, a menu button 104, a push-button 106 for powering the device on / off and for locking the device, a volume control button 108, a subscriber identity module (SIM) card slot 110, a headset jack 112, and a docking / charging external port 124. The push-button 106 can be used to power the device on / off by pressing the button and holding it in the pressed state for a predefined time interval; to lock the device by pressing the button and releasing it before the predefined time interval has elapsed; and / or to unlock the device or initiate an unlocking process. In an alternative embodiment, device 100 also accepts voice input via microphone 113 for activating or deactivating certain functions. Device 100 includes various components, including but not limited to memory (which may include one or more computer-readable storage media), a memory controller, one or more central processing units (CPUs), peripheral interfaces, RF circuitry, audio circuitry, a speaker 111, a microphone 113, an input / output (I / O) subsystem, and other input or control devices. Device 100 may include one or more image sensors 164, one or more proximity sensors 166, and one or more accelerometers 168. Device 100 may include more than one type of image sensor 164. Each type may include more than one image sensor 164. For example, one type of image sensor 164 may be a camera, and another type of image sensor 164 may be an infrared sensor that can be used for face recognition. In addition or alternatively, the image sensors 164 may be associated with different lens configurations. For example, device 100 may include rear image sensors, one with a wide-angle lens and another with a telephoto lens. Device 100 may include Figure 1 Components not shown include, for example, an ambient light sensor, a point projector, and a floodlight.

[0024] Device 100 is merely one example of an electronic device, and device 100 may have more or fewer components than those listed above, some of which may be combined into a single component or have different configurations or arrangements. The various components of device 100 listed above are embodied in hardware, software, firmware, or combinations thereof, including one or more signal processing and / or application-specific integrated circuits (ASICs). Although Figure 1 The components are shown as being located on the same side as the touchscreen 150, but one or more components may also be located on the opposite side of the device 100. For example, the front side of the device 100 may include an infrared image sensor 164 for facial recognition and another image sensor 164 serving as a front camera of the device 100. The rear side of the device 100 may also include an additional image sensor 164 serving as a rear camera of the device 100.

[0025] Exemplary communication system in electronic devices Figure 2 This is a block diagram illustrating the components of an electronic device 100 communicating via a multipoint bus 220 according to one embodiment. The electronic device 100 may include an application processor 208 (also referred to herein as a “central processing unit”), a coexistence hub device 212 (also referred to herein as a “coexistence hub device”), SOCs 234A to 234N (collectively referred to herein as “SOC 234”), a sensor device 216, the multipoint bus 220, and structures 222A to 222N (collectively referred to herein as “structure 222”), as well as other components. Figure 2 The component shown may be part of the communication subsystem in electronic device 100. Electronic device 100 may include Figure 2 Additional components not shown (e.g., user interface).

[0026] Application processor 208 is a processing circuit in electronic device 100 for performing various operations. Application processor 208 may include one or more processing cores for executing various software programs and dedicated hardware circuitry for performing specialized functions such as image processing, security operations, machine learning operations, and audio signal processing. Application processor 208 may also perform operations to coordinate the operation of other components in electronic device 100, including coexistence hub device 212, SOC 234, and sensor device 216. Application processor 208 may include firmware or hardware essential for the end-to-end functional behavior of a given SOC. For example, SOC 234C may not be entirely independent, and SOC 234C may rely on application processor 208 to engage multipoint bus 220 to assist SOC 234C in achieving coexistence and higher-level software support when communicating with, for example, SOC 234B. Application processor 208 can operate in a variety of power modes, including a low-power mode in which application processor 208 shuts down most of its components to save power, and a high-power mode in which most of its components are active. The application processor 208 may also incorporate one or more communication components (e.g., a cellular modem), which may also be embodied as a separate SOC.

[0027] The coexistence hub device 212 is hardware, software firmware, or a combination thereof that coordinates the operation of the communication system (including, for example, the coexistence hub device 212 and SOC 234) and related components (e.g., sensor device 216) within the electronic device 100. For this purpose, the coexistence hub device 212 stores and executes operational policies for defining and / or coordinating the operation of the communication system and related components. The coexistence hub device 212 can also play an active role on the multipoint bus 220 to coordinate its actions with the application processor 208 and with other clients on the multipoint bus 220 (e.g., SOC 234 and / or sensor device 216). The operational policies can determine the real-time operation of components in the communication system (e.g., SOC 234) based, for example, on factors such as the operating conditions of the communication system. The coexistence hub device 212 may also include one or more communication subsystems that perform communication operations through various physical interfaces. By performing this coexistence operation locally at the communication subsystem, the application processor 208 can remain in low-power mode for a longer period of time, regardless of the activity in the communication subsystem, and also release the resources of the application processor 208 during its high-power mode. See below for reference. Figure 3 The details of the coexistence hub device 212 are described in detail. The coexistence hub device 212 can also perform functions other than coordinating the operations performed by the application processor 208.

[0028] Each SOC in SOC 234 is a circuit that, individually or in combination with software or firmware, performs operations for communicating with one or more external networks or devices using communication or security protocols. It should be noted that this does not mean that each SOC in SOC 234 is completely independent. At least a portion of the firmware and / or software essential to the behavior of the SOCs on device 100 may exist on, for example, the application processor 208 due to the complexity of interactions with other components on the multipoint bus 220, or may heavily depend on another SOC on device 100 due to shared radio components or the use of overlapping or nearby spectra. Each of SOC 234 and coexisting hub device 212 may handle different communication protocols and / or be associated with different radio frequency bands. For example, SOC 234A may perform processing for long-range communication (e.g., cellular communication), SOC 234B or coexisting hub device 212 may handle short-range communication (e.g., Bluetooth communication), and SOC 204C may perform processing for, for example, WiFi communication. The operation of SOC 234 is controlled at least in part by the coexistence hub device 212. See below for reference. Figure 4 A detailed description of an example of the SOC 234B is provided. A pair of SOCs (e.g., SOC 234B and SOC 234C) can cooperate with each other using a multipoint bus 220 or general purpose input / output (GPIO) communication (e.g., GPIO 228C). See below for reference. Figures 5 to 7 Further details are provided regarding the collaboration between a pair of SOCs or between the coexisting hub device 212 and the SOC.

[0029] Sensor device 216 is a hardware component, either alone or in conjunction with firmware software, that senses various characteristics. This sensor device 216 generates sensor signals representing the sensed characteristics, which can be sent to other components (e.g., SOC 234, coexistence hub device 212, and application processor 208) for further processing. Sensor device 216 may be a Global Navigation Satellite System (GNSS) module used to enhance the reception of cellular wireless signals or connectivity systems, such as WiFi at SOC 234A. When sensor device 216 is not connected to multipoint bus 220, sensor device 216 may rely on, for example, SOC 234A as a channel for any events occurring outside of device 100. Sensor device 216 can assert its preferences when SOC 234A is arbitrating requests from external components (e.g., any SOC from SOC 234B to SOC 234N, coexistence hub device 212) that may affect the behavior of sensor device 216. In one or more embodiments, sensor device 216 may be a simple, standalone device that interacts with one or more SOCs in SOC 234, but still has coexistence issues with other components of electronics device 100. In one or more embodiments, sensor device 216 may be a complex sensor with an embedded processor and memory that sends or receives a wide range of messages with one or more SOCs in SOC 234. It should be noted that sensor device 216 is not necessarily required to have its own connection to multipoint bus 220. In some embodiments, it is not possible for sensor device 216 to be directly connected to multipoint bus 220. In such cases, SOC 234A (or some other SOC) may listen for requests from sensor device 216, and upon receiving a request, SOC 234A may coordinate with coexistence hub device 212 to perform relevant actions associated with sensor device 216. For example, the transmit power of the SOC 234A may affect the sensor device 216, so the coexistence hub device 212 may instruct the radio path on the SOC 234A to be disabled, or may instruct the radio components of the SOC 234A to transmit at a lower power or be temporarily disabled to accommodate the operation of the sensor device 216.

[0030] Structure 222 is a communication channel that enables components in the communication system to communicate with application processor 208. One or more structures in structure 222 can be implemented as point-to-point connections, such as PCIe, I2C, Serial Peripheral Interface (SPI), Universal Asynchronous Receiver Transmitter (UART) connections, or some other point-to-point connection. Figure 2 As shown, SOC 234A, coexisting hub device 212, and SOCs 234B to 234N communicate with application processor 208 via corresponding structures 222A to 222N. Compared to multi-point bus 220, one or more structures in structure 222 can have high bandwidth and low latency. Figure 2 The structure 222 shown can be a physically separate communication channel or one or more shared physical channels with multiple logical sub-channels.

[0031] Multipoint bus 220 is a communication channel that enables multiple components to communicate via a shared connection. Multipoint bus 220 can primarily be used to transmit coexistence messages between components in a communication system. However, multipoint bus 220 can also transmit other types of signals. Furthermore, multipoint bus 220 can be divided into more buses. In one or more embodiments, a System Power Management Interface (SPMI) is used to represent multipoint bus 220. Other serial bus interfaces such as I2C can be used instead of SPMI to represent multipoint bus 220.

[0032] In addition to or alternatively to the multipoint bus 220, general purpose input / output (GPIO) communication can be used between components within or outside the communication system. A GPIO connection represents a configurable direct connection between two subsystems. GPIO can be used for various reasons, including but not limited to (i) supporting legacy devices, (ii) providing a separate communication channel for time-sensitive information, (iii) supporting low-cost devices lacking or without the processing capabilities for decoding coexisting messages, (iv) enabling communication with devices that may encounter problems with transmission over the multipoint bus due to, for example, exposure to interference, and (v) providing dual support for both GPIO communication and communication over the multipoint bus. Figure 2As shown, sensor device 216 can communicate directly with SOC 234A via GPIO 228A, coexistence hub device 212 can communicate directly with SOC 234B via GPIO 228B, and SOC 234B can communicate directly with SOC 234C via GPIO 228C. Sensor device 216 can send low-latency data to SOC 234A via GPIO 228A, and simultaneously send latency-tolerant data to SOC 234A or other components via multipoint bus 220. In one embodiment, when device 216 is not a sensor device but a low-cost SOC or a functional split that cannot support direct connection to multipoint bus 220, GPIO 228A represents a direct communication device for device 216 to communicate with SOC 234A. SOC 234A can then utilize multipoint bus 220 to coordinate suppression with other devices that may be affected by the behavior of device 216. Although in Figure 2 Not shown, but SPI, PCIe, or both SPI and PCIe can be used to provide alternative or additional communication mechanisms. SPI, I2C, PCIe, UART, or some other point-to-point connections ( Figure 2 (Not shown) can be used for low-latency communication between coexisting hub device 212 and SOC 234B and / or between SOC 234B and SOC 234C.

[0033] Despite Figure 2 Although not shown, the coexistence hub device 212 can also control the operation or access to one or more antennas, RF switches, or other shared / coexisting RF components (not shown) associated with the communication system. In cases where the coexistence hub device 212 controls essential RF components on which another SOC (e.g., SOC 234B) depends, a GIPO (e.g., GPIO 228B) can be used to trigger a request for a state change of the shared / coexisting RF component.

[0034] Exemplary architecture of coexisting hub devices Figure 3 This is a block diagram illustrating a coexistence hub device 212 according to one embodiment. The coexistence hub device 212 is part of a communication system that coordinates the operation of components within the communication system that have more autonomy than other components in the communication system that are more closely dependent on supervision from the application processor 208. The coexistence hub device 212 can also handle communication via protocols that are different from or partially overlap with the communication performed by the SOC 234.

[0035] For this purpose, among other components, the coexistence hub device 212 may include a processor 304, coexistence control circuitry 314, a structural interface 310, a multipoint interface 340, a communication subsystem 336, and an internal structure 342. The coexistence hub device 212 may include... Figure 3 Additional components not shown in the diagram, or which may be omitted. Figure 3 The components shown.

[0036] Processor 304 is a circuit that, alone or in conjunction with software or firmware, uses coexistence messages to control the overall operation of coexistence hub device 212 and possible coordinated operations of SOC 234, for example, to notify SOC 234 of actions being taken by processor 304 or requests for changes in behavior required for SOC 234. Processor 304 may include memory to store an operation policy 352 for controlling operations. Operation policy 352 may be received from application processor 208 via structure 222B, structure interface 310, and internal structure 342. Upon receiving operation policy 352, processor 304 may decode operation policy 352 and, if applicable, program other components in coexistence hub device 212 (e.g., coexistence control circuitry 314) to execute operation policy 352. Furthermore, processor 304 can program SOC 234 to operate according to operation policy 352 by sending a portion of operation policy 352 related to SOC 234 via multipoint bus 220, without coordination tightly coupled to external supervision such as application processor 208. Processor 304 can make coexistence decisions according to operation policy 352 by analyzing coexistence messages (e.g., status information or requests) received from SOC 234 and communication subsystem 336 via interface 340. Processor 304 can store the current state 354 of one or more SOCs in communication subsystem 336 and SOC 234 in coexistence hub device 212. Processor 304 can delegate some coordination operations (e.g., coordination for communication subsystem 336) to arbitrator 322, which may be a hardware component or can be implemented entirely in firmware / software.

[0037] Operational strategy 352, as described herein, refers to scenarios involving combinations of operations in a communication system, which may be combinations of problematic or interoperable components. Operational strategy 352 also refers to a set of rules that define the actions to be taken by SOC 234 and coexistence hub device 212 to resolve or address such problematic scenarios, which typically also include transmit power coordination or the use of shared media. Such rules can be designed to take into account various considerations, including but not limited to resource usage, interference from shared or overlapping communication bands, and power usage. In one or more embodiments, the rules may be stored in the form of lookup tables. These lookup tables may be accessed by hardware, software, firmware, or a combination thereof in processor 304 to implement operational strategy 352.

[0038] The processor 304 can also communicate with the SOC 234 or other components in the electronic device 100 via GPIO. Although Figure 2 and Figure 3 A coexistence hub device 212 communicating with the SOC 234B is shown, but GPIOs may be omitted or additional GPIOs may be provided to communicate with other components in the electronic device 100.

[0039] In one implementation, when the coexistence hub device 212 is powered on during boot time (e.g., during initialization), processor 304 receives the entire operation policy 352 from application processor 208. After this moment, processor 304 can continue to incrementally update the relevant portion of operation policy 352 using structure 222B or the connection to application processor 208 via multipoint bus 220. In other implementations, processor 304 receives the relevant portion of operation policy 352 from application processor 208 when communication subsystem 336 and / or SOC 234 is powered on. In this implementation, the power-on of communication subsystem 336 and / or SOC 234 can be communicated to application processor 208, causing application processor 208 to send the relevant portion of operation policy 352 to processor 304.

[0040] In another embodiment, processor 304 is pre-loaded with operation policy 352. In this embodiment, processor 304 does not receive operation policy from application processor 208.

[0041] The communication subsystem 336 includes circuitry for processing signals received from or transmitted to a physical layer (PHY) interface 308 external to the coexisting hub device 212. Although Figure 3A communication subsystem 336 is shown embedded within the coexistence hub device 212; however, in some embodiments, the communication subsystem 336 is external to the coexistence hub device 212 and connected to it via a PHY interface 308. In such cases, the communication subsystem 336 will continue to access PHY interfaces such as PHY interface 308 to control external components. Such circuitry may include a local processor 378 performing one or more of the following operations: (i) executing commands associated with a specific communication protocol; (ii) processing received input communication signals according to the corresponding protocol to decode input radio signals and to receive communication messages from arbitrator 322 or processor 304 regarding actions being taken by coexisting hub device 212 and from scheduler 312 regarding external subsystems; (iii) controlling associated RF paths to adjust transmit power, receive gain control, change some key parameters (such as decisions) on the RF path to enable auxiliary receivers (e.g., for receive diversity) or auxiliary transmitters (e.g., for uplink multiple-input multiple-output (UL MIMO) communication) or enable auxiliary RF bands to support the current receive operation of communication subsystem 336; and (iv) configuring, disabling, or enabling components in communication subsystem 336 based on operating policy 352 or based on information about other active components determined from scheduler 312.

[0042] When the coexistence hub device 212 is powered on, the local processor 378 of the communication subsystem 336 can be initialized (e.g., via application processor 208 or automatically). Alternatively, when disconnected from the coexistence hub device 212, such as when all subsystems are not required to be part of the operation of device 100, the local processor 378 can operate independently. At some point, the local processor 378 can be initialized using information about how to act when it receives messages about the activity of external components (e.g., the activity of SOC 234B). Among other things, the local processor 378 is programmed with a portion of an operation strategy 352 relating to the operation of its communication subsystem 336. The portion of the operation strategy 352 downloaded to the local processor 378 of the communication subsystem 336 can define how the communication subsystem 336 should operate (e.g., defining the data rate of the communication subsystem, turning components on or off in the communication subsystem 336, and changing the number of active transmitters or receivers). Alternatively, with the communication system 336 enabled, the relevant portion of the operation strategy 352 can be downloaded and directly programmed by the application processor 208 via structure 222B or by the processor 304. The communication subsystem 336 can communicate with a physical layer interface (e.g., an RF device) via, for example, a radio frequency front-end control interface (RFFE). The communication subsystem 336 can coordinate with external subsystems to vote on preferences / controls for shared external components, coordinate with other communication components of the coexisting hub device 212, and coordinate with those subsystems connected to the multipoint bus 220.

[0043] Interface 340 is hardware circuitry or a combination of hardware circuitry, software, and firmware for communicating with multipoint bus 220. In one or more embodiments, interface 340 includes circuitry for processing data into outbound datagrams for transmission via SPMI and for unpacking inbound datagrams into data. Interface 340 is connected to processor 304 and coexistence control circuitry 314 via connection 328.

[0044] Structure interface 310 is hardware circuitry or a combination of hardware circuitry, software, and firmware used to enable coexistence hub device 212 to communicate with application processor 208 via structure 222B. In one or more embodiments, structure interface 310 performs operations such as buffering, segmenting / combining data, serializing / deserializing, and packaging / unpacking data for communication via a point-to-point communication channel (e.g., PCIe). Figure 3 As shown, the structural interface 310 is connected to the internal structure 342 to enable communication between the components in the coexisting hub device 212 and the application processor 208.

[0045] The coexistence control circuit 314 is a standalone circuit or a circuit integrated with firmware or hardware that processes coexistence messages transmitted via the multipoint bus 220. The coexistence control circuit 314 is programmed by the processor 304 to execute the operation strategy 352 by making real-time decisions on coexistence events, publishing inbound coexistence messages to the relevant communication subsystem 336, sharing real-time coexistence messages with the communication subsystem 336, and sending outbound coexistence messages to the SOC 234. The coexistence hub device 212 can also send monitoring link control messages to the SOC 234. The coexistence events described herein refer to conditions or occurrences defined by the coordinated operation strategy 352 that prompts the operation of components within the electronic device 100.

[0046] Specifically, the coexistence control circuit 314 may include a scheduler 312, a memory 316, an arbitrator 322, a notice board 326, and other components. The scheduler 312 is a programmable circuit or a circuit combined with software or firmware, which is used to filter and send messages of each communication subsystem 336 to the memory 316.

[0047] Memory 316 has one or more buffers 318 associated with communication subsystem 336. The one or more buffers 318 receive and store inbound coexistence messages associated with communication subsystem 336 (received from components outside coexistence hub device 212 via multipoint bus 220). Inbound coexistence messages stored in buffers 318 can be sent to communication subsystem 336 via internal structure 342 (as shown by arrow 372) based on priority (e.g., time-sensitive data has higher priority than time-insensitive data). If communication subsystem 336 is inactive, the one or more buffers 318 store messages until communication subsystem 336 is turned on and becomes available to receive messages. The one or more buffers 318 also store outbound coexistence messages 348 (received from communication subsystem 336 via internal structure 342). Outbound coexistence messages are retrieved by scheduler 312 and are also sent to components outside coexistence hub device 212 via multipoint bus 220 based on priority (e.g., time-sensitive data has higher priority than time-insensitive data).

[0048] The memory 316 also includes a shared memory portion 320, which can be accessed by the arbitrator 322 to resolve conflicting use of resources and by the local processor 378 to exchange time-sensitive coexistence messages with the communication subsystem 336.

[0049] The notice board 326 is a circuit that, alone or in conjunction with software or firmware, stores status information 346 of the communication subsystem 336, status information of the SOC 234, or some basic link information of the communication subsystem 336. The status information 346 is received from the communication subsystem 336 and stored in the notice board 326 for access. The notice board 326 enables the communication subsystem 336 to obtain information about the status of the SOC 234 and / or knowledge about the communication subsystem 336, in order to provide more detailed messages to the SOC 234. Alternatively, the notice board 326 enables external components to accurately determine their operating context by accessing the status information 346 in the notice board 326.

[0050] Arbitrator 322 is a circuit that, alone or in conjunction with software or firmware, makes decisions on the real-time coordination of the operation of communication subsystem 336 and transmits these decisions to communication subsystem 336 via internal structure 342 and memory 316. Arbitrator 322 can also assist with asynchronous activities of external SOC 234 that may affect active subsystems within coexisting hub device 212. Decisions made by arbitrator 322 may include resolving competing demands for common resources between communication subsystems 336 with external components or between different communication subsystems 336 within coexisting hub device 212, or resolving requests for incompatible resources to communication subsystem 336. Arbitrator 322 makes decisions in real time, which allows it to remain effective for shorter time periods compared to decisions made at processor 304 to implement operating strategy 352. For this purpose, arbitrator 322 can access the current state 354 of communication subsystem 336 and the SOC 234 stored in processor 304. The algorithm used to resolve resource conflicts at arbitrator 322 can be adjusted based on the operating strategy 352 executed by processor 304. Arbitrator 322 can be programmed by processor 304 or application processor 208. Decisions made by arbitrator 322 may include controlling RFFE transactions associated with communication subsystem 336 to control the final agreed radio state between communication subsystems within coexisting hub device 212 and those outside coexisting hub device 212. An example of controlling RFFE transactions is controlling radio switching based on requests from external subsystems. Arbitrator 322 may include processor 323 to control the overall operation of arbitrator 322. In some implementations, arbitrator 322 may be implemented entirely in firmware or software.

[0051] In one or more implementations, the arbiter 322 communicates with components outside the coexistence hub device 212 via GPIO 228B to obtain low-latency data. For example, the arbiter 322 may receive sensor data from one or more sensors in sensor 216 and make real-time decisions. The arbiter 322 may need to coordinate with internal communication subsystem 336 and external subsystems before granting permission to the requesting sensor device 216 (or other relevant devices).

[0052] In one or more embodiments, processor 304 determines a larger-scale coordinated operation based on its operation strategy 352 and configures components of coexistence control circuitry 314, communication subsystem 336, and possible SOC 234 to implement operation strategy 352. On the other hand, arbitrator 322 coordinates smaller-scale real-time coexistence operations consistent with the larger-scale coordinated operation defined by operation strategy 352.

[0053] Exemplary architecture of SOC Figure 4 This is a block diagram of SOC 234B according to one implementation scheme. Although in Figure 4 The SOC234B is shown as an example, but other SOCs 234A, 234C to 234N may have the same or similar architecture as the SOC 234B.

[0054] SOC 234B is part of the communication system in electronic device 100 and can use its communication subsystem 436A and communication subsystem 436B (collectively referred to as "communication subsystem 436") to execute one or more communication protocols. Although Figure 4 Only two communication subsystems 436A and 436B are shown, but the SOC 234B may include more than two communication subsystems or only a single communication subsystem. Communication subsystems 436A and 436B may each be associated with different communication protocols, or both may be associated with the same communication protocol. Communication subsystem 436 is substantially the same as communication subsystem 336, except that coexistence messages associated with communication subsystem 436 are processed by processor 412 instead of coexistence control circuitry 314.

[0055] In some implementations, SOC 234B is not entirely autonomous and may rely on application processor 208 or other components to (i) offload SOC 234B or (ii) coordinate other components essential to the behavior of SOC 234B, which may reside on or be directly controlled by application processor 208. Therefore, when a request for coexistence action arrives at SOC 234B from an external subsystem (e.g., from SOC 234C), more than one entity (e.g., SOC 234B and application processor 208) may be involved. Communication subsystem 436 may send coexistence messages via multipoint bus 220 to coexist with the communication subsystem and / or other SOCs 234A, 234C to 234N in the coexistence hub device. Inbound coexistence messages to SOC 234B are processed locally by processor 412 and sent to the corresponding communication subsystem 436. For the sake of brevity, this article omits further detailed explanations of the communication subsystem 436.

[0056] In addition to the communication subsystem 436, the SOC 234B may also include a structure interface 402, a bus interface 404, a processor 412, and an internal bus 440 for connecting these components, as well as other components. The SOC 234B may include additional components, such as memory for buffering coexistence messages associated with each communication subsystem 436.

[0057] Bus interface 404 is a circuit that, alone or in combination with software or hardware, enables components of SOC 234B to communicate with coexisting hub device 212 and other SOC 234A, SOC 234C to SOC 234N via multipoint bus 220.

[0058] Structure interface 402 is a circuit that, alone or in combination with software or hardware, enables components of the SOC 234B to communicate with the application processor 208 via structure 222C. Communication via structure interface 402 can transmit data at faster speeds and with higher bandwidth than communication via bus interface 404.

[0059] Processor 412 manages the overall operation of SOC 234B. Processor 412 may include interrupt manager 416 and message filter 418 as software or hardware components to, for example, identify which incoming messages are applicable to the current operating conditions of SOC 234B.

[0060] Interrupt manager 416 is hardware, software, firmware, or a combination thereof that manages interrupts. When interrupt manager 416 receives a coexistence message 442 including an interrupt, interrupt manager 416 extracts the interrupt and sends an interrupt signal 414 to communication subsystem 336. Interrupt signal 414 can cause communication subsystem 336 to shut down, power down a subset of its components, wake up from power-down mode, or indicate the real-time status of components (e.g., SOC 234) on multipoint bus 220. Interrupt signal 414 may involve only a simple decoder and no microprocessor, which allows low-cost components to send interrupt signals to transmit simple coexistence messages via multipoint bus 220. Even when other components of SOC 234B are in a radio inactive state or a deep sleep state, interrupt signal 414 generated by processor 412 can enable SOC 234B to respond to external requests (e.g., received via GPIO 228B and / or GPIO 228C). In this scenario, the SOC 234B can be configured to respond to certain agreed-upon strategies or be configured to wake up the processor 412 to respond to external requests via GPIO 228B and / or GPIO 228C.

[0061] One characteristic of interrupt signals 414 is their stickiness, meaning that even if the SOC (e.g., SOC 234B) is in a sleep state when the coexisting hub device 212 sends an interrupt signal, the SOC (e.g., SOC 234B) can respond to the interrupt signal after waking up at a later time. Interrupt signals 414 can also be used to ensure that an external SOC (e.g., SOC 234B) can abruptly transition to an inactive / sleep state without requiring other components (e.g., SOC 234A) to remain awake long enough to complete the handshake operation with the SOC (e.g., SOC 234B). By using always-on interrupt signals 414, the burden on the initial message source can be reduced. Even when the SOC 234B is in a deep sleep state, a sticky interrupt signal 414 with doorbell-optional behavior for waking up the processor 412 can coordinate state changes on the shared radio component, thereby enabling the SOC 234C and the coexistence hub device 212 to have greater flexibility in how the SOC 234C and the coexistence hub device 212 interact with the SOC 234B to use the shared radio component.

[0062] Message filter 418, which is hardware, software, firmware, or a combination thereof, receives inbound coexistence messages from multipoint bus 220 via bus interface 404, filters inbound coexistence messages 422 based on their association with communication subsystem 336 before sending filtered inbound coexistence messages, and sends the filtered inbound coexistence messages to one or more buffers 318 and / or shared portions 320 of memory 316. Message filter 418 can also redirect inbound coexistence messages 422 to one or more buffers (which may be organized by priority) associated with communication subsystem 336 to ensure that communication subsystem 336 receives all relevant inbound coexistence messages. If the inbound coexistence message includes an interrupt, message filter 418 sends the corresponding coexistence message 442 to interrupt manager 416.

[0063] The processor 412 can also communicate with other components of the electronic device 100 via GPIO. Figure 4 In this example, processor 412 is shown communicating with coexisting hub device 212 via GPIO 228B and with SOC 234C via GPIO 228C. However, GPIO 228B and / or GPIO 228C may be omitted, or additional GPIOs may be provided for processor 412 to communicate directly with other components of electronics 100 to transmit time-sensitive data. When coupled together, GPIO 228B and GPIO 228C can be used to request actions with defined priorities and / or defined durations. This allows external devices to accommodate situations where SOC 234B cannot immediately respond to a received request for an action, as SOC 234B may need to coordinate with one or more external devices on multipoint bus 220 before initiating the requested action.

[0064] Processor 412 and / or communication subsystem 436 can be programmed by processor 304 or application processor 208 of coexisting hub device 212 to implement operation strategy 352. In one embodiment, such programming can be performed when SOC 234B is powered on.

[0065] Exemplary block diagram of coordinating SOC Figure 5 This is a block diagram illustrating the coordination between a pair of subsystems of an electronic device 100 according to an implementation scheme. Figure 5 In an exemplary implementation, the SOC 234B coordinates activities with the SOC 234C via the multipoint bus 220 and GPIO 228C, or the SOC 234B and SOC 234C are individually controlled to allow the coordinated activities to continue, specifying the relevant status of the components. Figure 5 The SOC234B shown includes the above-mentioned combination Figure 4The bus interface 404 and processor 412 are described. The SOC 234B may include additional components omitted for brevity. Similarly, as Figure 5 The illustrated SOC 234C includes a bus interface 502 and a processor 504. The bus interface 502 operates in the same manner as the bus interface 404, and the processor 504 operates in the same manner as the processor 412. The SOC 234B is connected to the SOC 234C via the bus interface 404, the multipoint bus 220, and the bus interface 502. The coordination system presented herein allows cooperation between the SOC 234B and the SOC 234C regardless of the individual radio states of the SOC 234B and SOC 234C. Therefore, even if the SOC 234B is otherwise deactivated, the SOC 234B can still act upon requests from the SOC 234C. Furthermore, the processor 412 of the SOC 234B is directly connected to the processor 504 via GPIO 228C. Alternatively, instead of the multipoint bus 220, PCIe, I2C, SPI, UART, some other point-to-point connections (…) Figure 5 (Not shown) can be used for low-latency communication and activity coordination between SOC 234B and SOC 234C.

[0066] like Figure 5 As shown, the SOC 234C also includes features consistent with those described in the reference above. Figure 3 Arbitrator 506 operates in the same manner as arbitrator 322. Arbitrator 506 may be part of processor 504, for example, as... Figure 5 The processor 504 shown is a hardware or software component. Alternatively, the arbitrator 506 may be a separate component, for example, a hardware or software component separate from the processor 504. The arbitrator 506 may be configured to communicate with all subsystems involved in the decision-making process to determine the winning device for one or more shared resources and to determine the appropriate time for the winning device to gain control of the one or more shared resources. Figure 5The SOC 234C can be replaced by a coexistence hub device 212 to coordinate its activities with the SOC 234B in substantially the same manner as the SOC 234C. In this case, GPIO 238C will be replaced by GPIO 238B, bus interface 502 will be replaced by interface 340, processor 504 will be replaced by processor 304, and arbitrator 506 will be replaced by arbitrator 322. In some embodiments, the functionality of arbitrator 506 may reside at least partially in application processor 208. In such cases, the functionality of arbitrator 506, as part of application processor 208, will primarily operate in the always-on domain (which is application processor 208), allowing arbitrator 506 to arbitrate different SOCs simultaneously based on information from other processes that are not always active (e.g., executed at other SOCs).

[0067] To request authorization to perform an activity on the SOC 234B, the processor 412 may generate an authorization request and send it via bus interface 404 and multipoint bus 220. The SOC 234C may receive the authorization request from the SOC 234B via multipoint bus 220 and bus interface 502. The authorization request includes at least one of the following: information about parameters of the activity; information about one or more resources of the SOC 234C used by the SOC 234B during the activity (e.g., media, RF frequency, communication band, duration of the request to use one or more resources, etc.); information about the time period of the activity; information about the persistence of the authorization request (e.g., multiple authorization requests previously sent to authorize activities that have not yet been authorized); information about the priority of the authorization request; information about the priority of the requested activity; or some other information related to performing the activity at the SOC 234B.

[0068] Upon receiving an authorization request, SOC 234C can determine whether to authorize SOC 234B to perform the activity. In some embodiments, arbitrator 506 determines whether to authorize SOC 234B to perform the activity. In one or more embodiments, the authorization of SOC 234B to perform the activity can be determined by a set of rules active in arbitrator 506. Such rules can be defined at least in part by an operation policy 352 active in coexisting hub device 212. Arbitrator 506 can also examine operations currently being performed or scheduled to be performed during the requested activity and determine whether to reject the requested activity based on current or future activity. Arbitrator 506 (e.g., in combination with one or more software processes running on processor 504 and / or application processor 208) can also ensure that external critical dependencies of SOC 234B (e.g., RF filters) are in a proper state, so that SOC 234B and SOC 234C are compatible with each other and can coordinate their activities within defined time constraints. In one or more implementations, the SOC 234B may also be authorized to perform activities on behalf of the SOC 234C.

[0069] In some other embodiments, after receiving an authorization request from the SOC 234B via the multipoint bus 220 and bus interface 502, the processor 504 may initiate an interrupt service routine (ISR). The ISR running on the processor 504 represents a software-based arbitrator that generates an appropriate response signal for the SOC 234B, for example, based on the operating policy 352 active in the coexistence hub device 212. In one embodiment, the ISR may generate an authorization signal for the SOC 234B authorizing the requested activity at the SOC 234B. In another embodiment, the ISR may generate a rejection signal for the SOC 234B, denying the SOC 234B access to the resources used for the requested activity. In another implementation, the ISR can generate coordination signals to coordinate activities between the SOC 234B and SOC 234C that are different from authorization / denial activities (e.g., setting external components (e.g., RF filters) of the SOC 234B and / or SOC 234C to a compatible state, ensuring that the SOC 234B and SOC 234C can cooperate with each other), exchange information about the exact timing of changes in the state of components or scheduled activities, or perform some other coordination.

[0070] Processor 504 of SOC 234C can send a response signal (e.g., an authorization signal, a rejection signal, or a coordination signal) to processor 412 of SOC 234B via GPIO 228C. In one embodiment, after determining (e.g., via arbitrator 506 or via ISR) to authorize SOC 234B to perform the requested activity, processor 504 of SOC 234C sends an authorization signal authorizing SOC 234B to perform the requested activity to processor 412 via GPIO 228C. Communication via GPIO 228C has lower latency compared to communication via multipoint bus 220, and therefore, sending the authorization signal using GPIO 228C enables SOC 234B and SOC 234C to coordinate time-sensitive operations associated with resource usage. Based on the authorization signal received from SOC 234C via GPIO 228C, SOC 234B can use one or more resources of SOC 234C to perform an activity, for example, for a time period less than a threshold time period. In another embodiment, the processor 504 of the SOC 234C sends a rejection signal to the processor 412 via GPIO 228C, refusing to provide the SOC 234B with resources to perform the requested activity after determining (e.g., via arbitrator 506 or via ISR) that the SOC 234B is not authorized to perform the requested activity.

[0071] In yet another implementation, the processor 504 of the SOC 234C can exchange one or more coordination signals with the processor 412 via GPIO 228C to coordinate activities between the SOC 234B and the SOC 234C other than authorization / denial activities. The one or more coordination signals sent via GPIO 228C can allow different layers or portions of communication between the SOC 234B and the SOC 234C to be transmitted via GPIO 228C and the multipoint bus 220. For example, non-time-sensitive signals between the SOC 234B and the SOC 234C can be sent via the multipoint bus 220, while time-sensitive signals can be transmitted via GPIO 228C.

[0072] In some implementations, after the processor 412 of the SOC 234B sends an authorization request via bus interface 404 and multipoint bus 220, the processor 504 of the SOC 234C receives the authorization request via bus interface 502 and multipoint bus 220 with a first delay less than a first time limit. After receiving the authorization request, the processor 504 can also send an authorization signal (or rejection signal) via GPIO 228C with a second delay less than a second time limit. The second time limit can be shorter than the first time limit. The processor 504 can send the authorization signal via GPIO 228C according to its local timing, meaning that the processor 504 can immediately enqueue transactions for communication via GPIO 228C within a limited time period after receiving the authorization request or after receiving the authorization request using the processor 504's internal timer. The processor 504 can process the received authorization request within a limited time limit after receiving it.

[0073] Processor 504 can send a request to SOC 234B via GPIO 228C to release one or more resources (e.g., media, communication band, RF antenna, etc.) used during the activity of SOC 234B. In one or more embodiments, processor 504 or processor 412 can send a coordination signal via GPIO 228C to another subsystem (e.g., SOC 234B or SOC 234C) to coordinate resources between SOC 234B or SOC 234C (e.g., setting the RF filters of SOC 234B and / or SOC 234C to an appropriate state, or restricting the use of the RF antenna by one subsystem), making the two subsystems compatible and able to coordinate their activities with each other. In one or more other embodiments, GPIO 228C can be used to signal critical blocking activities between SOC 234B and SOC 234C as a coordinated operation between the two subsystems. In this scenario, a blocking signal can be sent via GPIO 228C to indicate that a task from a pre-agreed set of permitted tasks is about to be executed, for example, at the SOC 234B. Based on the critical blocking activity previously signaled via GPIO 228C, the SOC 234C can relinquish its use of one or more resources within a defined time limit. The SOC 234C can then send an grant signal via GPIO 228C to allow the SOC 234B to take over one or more resources and execute the SOC 234B's critical tasks.

[0074] Processor 504 can also monitor the status of at least one resource of SOC 234C during the activity of SOC 234B. During the activity of SOC 234B, processor 504 can receive another authorization request from SOC 234B via multipoint bus 220 and bus interface 502. Other authorization requests can use at least one resource of SOC 234C to seek authorization to perform another activity at SOC 234B. Based on the monitored status of at least one resource, processor 504 can generate (e.g., via arbitrator 506) an appropriate response signal for SOC 234B, such as an authorization signal or a rejection signal. Processor 504 can send the appropriate response signal (e.g., authorization signal or rejection signal) to processor 412 via GPIO 228C. Considering one or more current actions on at least one resource of SOC 234B (e.g., one or more shared radio components) to be completed according to, for example, a network protocol, the response signal may be time-delayed before SOC 234B can allow SOC 234C to take over at least one resource.

[0075] According to embodiments of this disclosure, SOC 234B and SOC 234C are dynamically connected via multipoint bus 220 and GPIO 228C, enabling both SOC 234B and SOC 234C to exchange messages for coordination with each other via multipoint bus 220 and GPIO 228C. Coordination is not limited to authorizing and denying activity at one of SOC 234B and SOC 234C. GPIO 228C can also be used for other coordination of activities in SOC 234B and SOC 234C, where, for example, based on one or more messages exchanged via GPIO 228C, external components of SOC 234B and SOC 234C (e.g., filters of the RF front end) are set to a known / compatible state. Therefore, GPIO 228C represents a mechanism for ensuring that one subsystem controls the state of the front end of another subsystem for coordinated operation of the two subsystems (e.g., SOC 234B and SOC 234C). GPIO 228C (alone or with multipoint bus 220) can be used for real-time signaling to control the concurrent resources of multiple subsystems (e.g., SOC 234B and SOC 234C), so that one subsystem (e.g., SOC 234B) can directly control one or more dependent resources on another subsystem (e.g., SOC 234C), thereby keeping the one or more dependent resources in a compatible state.

[0076] Alternatively or otherwise, GPIO 228C can be used to control activities on the corresponding subsystem (e.g., SOC 234B), such as blanking the transmitter path, changing the transmit antenna used on the corresponding subsystem, controlling one or more front-end components of the corresponding subsystem, controlling the critical state of the corresponding subsystem, allowing activities to occur on another subsystem, or some other coordination. SOC 234C can send an indication signal to SOC 234B in real time via GPIO 228C, indicating that SOC 234B is now authorized to actively reuse requested resources (e.g., media, communication band, etc.). Furthermore, SOC 234C can send a blocking signal to SOC 234B via GPIO 228C to block SOC 234B from performing any tasks with a priority lower than a threshold priority, so that only tasks with a predefined priority higher than the threshold priority are allowed to be performed at SOC 234B (e.g., any tasks related to the reservation of the communication link between SOC 234B and SOC 234C). In addition, in response to the SOC 234C rejecting an activity at the SOC 234B a predetermined number of times, the SOC 234C can send a final authorization signal to the SOC 234B to perform the activity via GPIO 228C.

[0077] In some implementations, GPIO 228C can be used to send one or more messages in advance between SOC 234B and SOC 234C to coordinate the operation of SOC 234B and SOC 234C. GPIO 228C can transmit the precise timing of changes and / or actions that will occur on other subsystems within one or more messages. Therefore, signals sent via GPIO 228C represent key “action triggers” that cause SOC 234B and / or SOC 234C to take certain actions. GPIO 228C is particularly valuable for subsystems where coexistence messages via multipoint bus 220 are executed by different parts of the software running, such as processor 412 of SOC 234B and / or processor 504 of SOC 234C, such that processor 412 and / or processor 504 may not have a context for precise timing controlled by a lower-level physical layer. In such cases, GPIO 228C facilitates coordinated communication between SOC 234B and SOC 234C by transmitting coexistence messages between SOC 234B and SOC 234C.

[0078] In some implementations, the coexistence hub device 212 can send a request for timing information to, for example, the SOC 234B via GPIO 228B. This timing information indicates that one or more resources (e.g., media, bandwidth, etc.) have become available for release by the SOC 234B to one or more other subsystems. In response to this request, the SOC 234B can send a response to the coexistence hub device 212 via GPIO 228B, notifying the coexistence hub device 212 of the time when the SOC 234B can release the one or more resources. The coexistence hub device 212 can request the SOC 234B (via the request sent via GPIO 228B) to asynchronously send the response via GPIO 228B to indicate that the SOC 234B will release its resources.

[0079] The electronic device 100 with multipoint bus 220 may include components (e.g., SOC 234B and / or SOC 234C) that may not support the communication protocols via multipoint bus 220 due to conventional design. Embodiments of this disclosure support only low-cost external components (e.g., SOC 234B and / or SOC 234C) that can be incorporated into the GPIO connections of the electronic device 100 with multipoint bus 220. These external components (e.g., SOC 234B and / or SOC 234C) can utilize the arbiter 322 of the coexistence hub device 212 or its own arbiter (e.g., arbiter 506 of SOC 234C) to observe GPIO connections (e.g., GPIO 228C), enabling the corresponding external component (e.g., SOC 234C) to coexist with another external component (e.g., SOC 234B), wherein, for example, in terms of the sharing or incompatible use of one or more resources (e.g., frequency band, medium, etc.), SOC 234B and SOC 234C are the most exposed in all subsystems of electronic device 100. GPIO connections (e.g., GPIO 228C) can allow lower-cost subsystems (e.g., SOC 234B and / or SOC 234C) to collaborate and function with higher-level subsystems of electronic device 100 (e.g., coexistence hub device 212 and / or SOC 234A).

[0080] In one or more implementations, the SOC 234B continues with a hypothetical authorization to perform the requested activity. In such cases, the SOC 234B may simply inform the SOC 234C (e.g., via GPIO 228C) of its expected action, assuming an implicit response from the SOC 234C. In one or more other implementations, the SOC 234B sends an authorization request seeking authorization to perform the activity to the SOC 234C via multipoint bus 220 or GPIO 228C, and the SOC 234B may rely on the SOC 234C to complete the activity when conditions permit.

[0081] Exemplary process for coordinated coexistence operations Figure 6 This is an interactive diagram illustrating the operation of components in an electronic device 100 according to one embodiment. Figure 6 The interactive diagram illustrates an example of coordinated operation between a pair of components of electronic device 100, such as coordination between SOC 234B and SOC 234C (or coexistence hub device 212).

[0082] During the time period when the scheduler of SOC 234B is running 602, SOC 234B may send a wake-up message 604 to SOC 234C (e.g., via multipoint bus 220). Upon receiving the wake-up message, SOC 234C may wake up 606 and enable its component devices or a subset thereof. During each scheduler run 602, SOC 234B may initiate 608 coordination with another component of electronic device 100 (e.g., SOC 234C or coexistence hub device 212).

[0083] During the same scheduler operation 602, SOC 234B can determine whether 610 should execute the activity scheduled by SOC 234B. If SOC 234B determines that 610 should execute the scheduled activity, SOC 234B can send 612 a request to SOC 234C (or to coexistence hub device 212) via multipoint bus 220 to execute the scheduled activity, for example, once wake-up 606 is determined to be complete. This request may include one or more pieces of information about the activity parameters, such as information about one or more resources of SOC 234C or coexistence hub device 212 that were requested to be released for use during the SOC 234B's scheduled activity. The activity parameters sent as part of the request can be written to the shared memory of SOC 234C or coexistence hub device 212 (e.g., shared memory portion 320). SOC 234C (or coexistence hub device 212) can receive the request via multipoint bus 220 within a first time limit after SOC 234B sends the request. The SOC 234B can further send 614 information about activity parameters to the SOC 234C or the coexistence hub device 212 via GPIO 228C. In one embodiment, the SOC 234B can send 614 to the SOC 234C (or the coexistence hub device 212) an indication to set the RF front end of the SOC 234C to an active state in preparation for scheduled activities at the SOC 234C.

[0084] In one implementation, upon receiving a request to perform a scheduled activity at SOC 234B, SOC 234C (or coexistence hub device 212) initiates 616 an ISR that can run on processor 508 of SOC 234C (or processor 304 of coexistence hub device 212). During the ISR, SOC 234C (or coexistence hub device 212) may decide whether to authorize the scheduled activity at SOC 234B, and SOC 234C (or coexistence hub device 212) generates an appropriate response message for SOC 234B. In another implementation, upon receiving a request to perform a scheduled activity at SOC 234B, arbitrator 510 of SOC 234C (or arbitrator 322 of coexistence hub device 212) executes an operating policy received from application processor 208 and determines 618 whether to authorize SOC 234B to run the scheduled activity. SOC 234C (or coexistence hub device 212) determines 618 whether to authorize SOC 234B to run scheduled activities during SOC 234C's (or coexistence hub device 212's) scheduler activity 620 (e.g., WiFi scheduler activity). After making the decision 618 on whether to authorize SOC 234B to run scheduled activities, SOC 234C (or coexistence hub device 212) sends a response message 622 to SOC 234B via GPIO 228C (or GPIO 228B). In one embodiment, the response message includes an authorization signal authorizing SOC 234B to perform scheduled activities. In another embodiment, the response message includes a rejection message indicating to SOC 234B that the scheduled activity is not authorized and that the requested resources are not released to SOC 234B. The rejection message may also include a "shutdown signal" instructing SOC 234B to shut down any resources (e.g., RF front-end) activated before the start of scheduled activities. The SOC 234C (or coexistence hub device 212) sends a 622 response message via GPIO 228C (or GPIO 228B) within a second time limit (e.g., shorter than the first time limit) after receiving a request for authorization to schedule activities at the SOC 234B.

[0085] Figure 7 This is a timing diagram illustrating the coordination of components in an electronic device 100 according to one embodiment via a shared bus. Figure 7In the illustrated implementation, SOC 234B and SOC 234C can coordinate their activities via a shared bus (e.g., a multipoint bus 220 coupled to GPIO 228C). Alternatively, instead of using multipoint bus 220, SOC 234B and SOC 234C can coordinate their activities via a point-to-point connection and GPIO 228C. Before time T1, SOC 234B can send a request for one or more resources (e.g., communication band, medium, etc.) to SOC 234C via, for example, multipoint bus 220 or GPIO 228C. At time T1, SOC 234B asserts 702 to GPIO 228C and obtains temporary control of one or more resources from SOC 234C. Assertion 702 indicates authorization for SOC 234B to temporarily use one or more resources. Upon observation of assertion 702, SOC 234C releases 704 the one or more resources requested by SOC 234B. For example, the SOC 234C can disable its own RF path, change its in-use radio antenna, or change its transmit power for a limited time period to allow the SOC 234B to initiate one or more activities. Note that if the SOC 234C has scheduled activities with a priority higher than a threshold priority, the SOC 234C can assert GPIO 228C (e.g., at time T2), and the SOC 234B will allow the SOC 234C to take over the resources required by the previously released (or disabled) scheduled activities (e.g., enabling the SOC 234C's RF path).

[0086] The SOC 234B uses at least one or more resources released by the SOC 234C to perform the activity requested in 706. The SOC 234B may initiate the requested activity at time T1 based on information that the implicit authorization time for using one or more resources at the SOC 234C has expired. Implicit behavior means that the SOC 234B can always acquire one or more resources based on implicit priority. However, the SOC 234C may assert its own need for a predefined set of tasks (e.g., via GPIO 228C) and retrieve at least some of the resources previously released to the SOC 234B. Alternatively, the SOC 234B may initiate the requested activity at time T1 by sending a signal at time T1 via the multipoint bus 220 indicating a high-priority context for the activity. This signal may be coupled with a transmission of another signal to the SOC 234C via GPIO 228C, where the SOC 234C has information about the timing of the resource release action required by the SOC 234C.

[0087] At time T2, SOC 234C initiates the execution of its own activity using available resources. Alternatively, SOC 234B and SOC 234C can communicate via multipoint bus 220 to negotiate in advance the actual timing of SOC 234C's activity for a given activity priority. Then, by utilizing GPIO 228C, SOC 234B and SOC 234C can dynamically coordinate better coupling for real-time coordination. At time T3, SOC 234B sends a request for at least one resource (e.g., a communication band) for another activity to be executed by SOC 234B, for example via multipoint bus 220 or GPIO 228C. However, because SOC 234C is executing an activity with a higher priority than other activities (e.g., performing critical functions at SOC 234C), requests for other activities are ignored or rejected by SOC 234C. Upon receiving another request, the SOC234C sends a signal 710 via the multipoint bus 220 indicating that resources are denied for other activities. Alternatively, when coordinating activities between the SOC 234B and SOC 234C using GPIO 228C, there is an implicit rejection of other activities at the SOC 234B, where there are predefined rules and expectations regarding how the SOC 234B and SOC 234C should respond to different signal transitions on GPIO 228C.

[0088] SOC 234C can generate a rejection signal (e.g., via arbitrator 510) based on a priority that determines the priority of the activity currently being performed by SOC 234C using at least one requested resource is higher than the priority of other activities requested to be performed by SOC 234B. Even before receiving any response from SOC 234C, such as at time T3, SOC 234B can initiate other activities (e.g., by activating its own resources for other activities, such as activation of the RF front end). However, upon receiving rejection signal 710 via multipoint bus 220, SOC 234B can shut down (e.g., deactivate) 712 any resources associated with the ignored / rejected activity, thereby effectively terminating the ignored / rejected activity at time T4.

[0089] Figure 8A This is a block diagram illustrating the coordination between a pair of subsystems of an electronic device 100 according to an implementation scheme. Figure 8AIn an exemplary implementation, SOC 234C coordinates with coexistence hub device 212 via multipoint bus 220 to grant (or deny) SOC 234B access to resources (e.g., media). It should be noted that in this example, SOC 234B is directly coupled to SOC 234C via GPIO 228C, and SOC 234B does not have any direct connection to multipoint bus 220. Therefore, SOC 234B and SOC 234C coexist to access resources. The ability of SOC 234C to grant SOC 234B access to resources may require coordination with, for example, coexistence hub device 212 via multipoint bus 220.

[0090] Figure 8B This illustrates a method from which an implementation plan is derived. Figure 8A The timing diagram for coordinating the components is as follows. At a certain point in time, the SOC 234B can send an 802-pair activity request to the SOC 234C via GPIO 228C (e.g., via one of GPIO 228C), seeking authorization from the SOC 234C to obtain access to resources for performing the requested activity. Simultaneously or nearly simultaneously with sending the 802-pair activity request, the SOC 234B can send an 804 priority / persistent signal to the SOC 234C via GPIO 228C relative to the requested activity. In one embodiment, the priority signal and persistent signal are sent from the SOC 234B to the SOC 234C as a single signal via, for example, one of GPIO 228C. In another embodiment, the priority signal and persistent signal are sent from the SOC 234B to the SOC 234C as two separate signals via, for example, a pair of GPIO 228C. Following internal arbitration performed by, for example, arbitrator 506 of SOC 234C, SOC 234C can generate an appropriate response to SOC 234B. Internal arbitration and response generation can be performed within a time Δt (e.g., Δt ≤ 30µs). After time Δt, SOC 234C can send GPIO 228C to SOC 234B via GPIO 806 to grant / deny access to the requested resource. This is typical if SOC 234C can autonomously decide on SOC 234B's request to grant access to the requested resource (e.g., media).

[0091] In one or more implementations, for example, if the coexistence hub device 212 notifies the SOC 234C via the multipoint bus 220 that the coexistence hub device 212 is currently using (or intends to use) a resource requested by the SOC 234B for a predetermined period of time, the SOC 234C may deny access to the resource by 806. In the case where the SOC 234C sends a rejection response of 806 to the SOC 234B, the assertion of the activity request and priority / persistence signal may no longer be asserted on GPIO 228C, and may need to be repeated on GPIO 228C after the defined period of time. In one or more other implementations, for example, if the coexistence hub device 212 notifies the SOC 234C via the multipoint bus 220 that the coexistence hub device 212 is not currently using (or does not intend to use) a resource requested by the SOC 234B for a predetermined period of time, the SOC 234C may grant access to the resource by 806.

[0092] Figure 9A This is a block diagram illustrating the coordination between a pair of subsystems of an electronic device 100 according to an implementation scheme. Figure 9A In an exemplary implementation, the SOC 234C coordinates with the coexistence hub device 212 via multipoint bus 220 to grant the SOC 234B access to at least one shared (or coexisting) resource 902. At least one shared resource 902 can be coupled to the SOC 234C via connection 904. It should be noted that in this example, the SOC 234B is directly coupled to the SOC 234C via GPIO 228C, the SOC 234B does not have any direct connection to the multipoint bus 220, and at least one resource 902 can be shared (coexisted) between the SOC 234C and the SOC 234B. The SOC 234B can typically operate independently of the SOC 234C. However, to grant access to at least one shared (coexisting) resource 902 (e.g., one or more RF bands), coordination between the SOC 234C and the coexistence hub device 212 via multipoint bus 220 for controlling at least one shared resource 902 may be crucial. The coexistence hub device 212 can also collectively depend on at least one shared resource 902. The arbitrator 506 of the SOC 234C can be configured to listen for input from the coexistence hub device 212, SOC 234B, and SOC 234C to determine which is in the preferred state for accessing at least one shared resource 902.

[0093] Figure 9B This illustrates a method from which an implementation plan is derived. Figure 9AThe timing diagram for coordinating the components. At a certain point in time, the SOC 234B can send a request for 912 pairs of activities to the SOC 234C via GPIO 228C (e.g., via one of GPIO 228C), seeking authorization from the SOC 234C to obtain access to at least one shared resource 902 for performing the requested activity. Simultaneously or nearly simultaneously with sending the request for 912 pairs of activities, the SOC 234B can send a priority signal / persistent signal to the SOC 234C via GPIO 228C relative to the requested activity. In one embodiment, the priority signal and persistent signal are sent from the SOC 234B to the SOC 234C as a single signal via, for example, one of GPIO 228C. In another embodiment, the priority signal and persistent signal are sent from the SOC 234B to the SOC 234C as two separate signals via, for example, a pair of GPIO 228C. Meanwhile, the SOC 234C can perform coordination 916 with external devices (e.g., coexistence hub device 212) via multipoint bus 220 for accessing at least one shared resource 902.

[0094] In scenario 910, after internal arbitration performed by arbitrator 506 of, for example, SOC 234C and coordination with coexistence hub device 212 on multipoint bus 220, SOC 234C can generate an appropriate response for SOC 234B. The internal arbitration, as well as the generation of at least a portion of the external coordination and response, can be performed within a time Δt (e.g., Δt ≥ 50 µs). After time Δt, SOC 234C can send grant / deny 918 to SOC 234B via GPIO 228C to grant or deny access to at least one shared resource 902. In one or more embodiments, for example, if arbitrator 506 knows, through coordination with coexistence hub device 212, that coexistence hub device 212 is currently using (or intends to use) at least one shared resource 902 within a defined time period, then SOC 234C can deny 918 access to at least one shared resource 902. In one or more other implementations, for example, if the arbitrator 506 knows, through coordination with the coexistence hub device 212, that the coexistence hub device 212 is not currently using (or does not intend to use) at least one shared resource 902, then the SOC 234C may grant the SOC 234B permission 918 to access at least one shared resource 902.

[0095] Alternatively, in scenario 920, after internal arbitration performed by, for example, arbitrator 506 of SOC 234C and external coordination with coexisting hub device 212 on multipoint bus 220, SOC 234C can perform 922 to configure at least one shared resource 902 to a new state. The internal arbitration and at least a portion of the external coordination can be performed within a time Δt (e.g., Δt ≥ 50 µs). The new state of at least one shared resource 902 can correspond to the state of at least one shared resource 902 preferred for an activity requested by SOC 234B. Once the configuration to the new state is complete, SOC 234B can be allowed to access at least one shared resource 902 to perform the requested activity.

[0096] Figure 10 This is a flowchart illustrating the process of coordinating the operation between components of an electronic device 100 according to one embodiment. Figure 10 The process shown can be performed by an integrated circuit (component or subsystem) of electronic device 100, such as coexistence hub device 212 or SOC (e.g., SOC 234C).

[0097] An integrated circuit (e.g., a coexistence hub device 212 or a SOC 234C) of electronic device 100 receives, via interface circuitry and a multipoint bus (or point-to-point connection), a license request 1002 seeking authorization to perform an activity on the other integrated circuit. The license request may include at least one of the following: information about parameters of the activity, information about one or more resources of the integrated circuit for use during the activity, information about the time period of the activity, and some other information related to the activity.

[0098] In response to receiving an authorization request, an integrated circuit (e.g., a coexistence hub device 212 or a SOC 234C) of electronic device 100 determines whether 1004 authorizes another integrated circuit to perform activities. In some embodiments, an arbitrator circuit connected to an integrated circuit with a configurable direct connection (e.g., GPIO 228B or GPIO 228C) is configured to execute a policy received from the central processing unit (application processor 208) of electronic device 100 to determine whether to authorize another integrated circuit to perform activities. In some other embodiments, the integrated circuit is configured to initiate an interrupt to generate an authorization signal in response to receiving an authorization request.

[0099] In response to determining that an activity is authorized to be performed by another integrated circuit, an integrated circuit of electronic device 100 (e.g., a coexistence hub device 212 or a SOC 234C) sends an authorization signal 1006 to the other integrated circuit via a configurable direct connection to authorize the other integrated circuit to perform the activity. The integrated circuit is configured to receive the authorization request via an interface circuit and a multipoint bus (or point-to-point connection) within a first time limit after the other integrated circuit sends the authorization request. The integrated circuit is further configured to send the authorization signal via a configurable direct connection (e.g., GPIO 228B or GPIO 228C) within a second time limit after receiving the authorization request. The second time limit may be shorter than the first time limit.

[0100] Figure 10 The processes and their sequences shown are merely illustrative. Additional processes can be added, and some can be omitted. Figure 10 Some of the processes involved.

[0101] While specific implementations and applications have been described and illustrated, it should be understood that the invention is not limited to the precise constructions and components disclosed herein, and that various modifications, alterations, and variations that will be apparent to those skilled in the art may be made to the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope of this disclosure.

Claims

1. A first integrated circuit, comprising: An interface circuit configured to communicate with a second integrated circuit via a communication channel in an electronic device; as well as Processor circuitry, the processor circuitry being configured to: The assertion signal received from the second integrated circuit via the communication channel indicates that the second integrated circuit requests control over one or more resources shared between the first integrated circuit and the second integrated circuit for a period of time. In response to receiving the assertion signal, the one or more resources requested by the second integrated circuit are released; as well as Upon detecting a scheduling event, a computational operation utilizing the one or more resources is initiated.

2. The first integrated circuit according to claim 1, wherein, In order to release the one or more resources, the processor circuitry is further configured to perform at least one of the following: Disable one or more radio frequency (RF) paths; Switching from using the first antenna to using the second antenna; and Modify the transmit power of the first integrated circuit.

3. The first integrated circuit according to claim 1, wherein, In order to release the one or more resources, the processor circuitry is further configured to release the one or more resources for a predetermined period of time.

4. The first integrated circuit according to claim 1, wherein, The scheduling event includes determining that the processor circuit has a scheduled computational operation, the scheduled computational operation having a scheduling priority that satisfies a threshold priority.

5. The first integrated circuit according to claim 1, wherein, The processor circuit is further configured as follows: During the computational operation initiated by the processor circuitry, a request for one or more resources is received from the second integrated circuit to perform another computational operation; as well as A rejection signal is provided to the second integrated circuit, the rejection signal indicating that the second integrated circuit is rejected by the one or more resources.

6. The first integrated circuit according to claim 5, wherein, In order to provide the rejection signal, the processor circuit is further configured to: The priority of the computation operation is determined to be higher than the priority of the other computation operation; as well as In response to determining that the priority of the computational operation is higher than the priority of the other computational operation, the rejection signal is provided to the second integrated circuit.

7. The first integrated circuit according to claim 5, wherein, In order to provide the rejection signal, the processor circuit is further configured to provide the rejection signal to the second integrated circuit via the communication channel.

8. The first integrated circuit according to claim 5, wherein, In order to provide the rejection signal, the processor circuitry is further configured to provide the rejection signal to the second integrated circuit via a configurable direct connection separate from the communication channel.

9. A method implemented by a first integrated circuit, comprising: An assertion signal is received from a second integrated circuit via a communication channel, the assertion signal indicating that the second integrated circuit requests control over one or more resources shared between the first integrated circuit and the second integrated circuit for a period of time; In response to receiving the assertion signal, the one or more resources requested by the second integrated circuit are released; as well as Upon detecting a scheduling event, a computational operation utilizing the one or more resources is initiated.

10. The method according to claim 9, wherein, Releasing the one or more resources includes at least one of the following: Disable one or more radio frequency (RF) paths; Switching from using the first antenna to using the second antenna; and Modify the transmit power of the first integrated circuit.

11. The method according to claim 9, wherein, Releasing the one or more resources includes releasing the one or more resources for a predetermined period of time.

12. The method according to claim 9, wherein, The scheduling event includes determining that the computational operation for scheduling at the first integrated circuit has a scheduling priority that satisfies a threshold priority.

13. The method of claim 9, further comprising: During the initiated computation operation, a request from the second integrated circuit for the one or more resources is received to perform another computation operation; as well as A rejection signal is provided to the second integrated circuit, the rejection signal indicating that the second integrated circuit is rejected by the one or more resources.

14. The method according to claim 13, wherein, Providing the rejection signal includes: Determine that the priority of the initiated computation operation is higher than the priority of the other computation operation; and In response to determining that the priority of the initiated computation operation is higher than the priority of the other computation operation, the rejection signal is provided to the second integrated circuit.

15. The method according to claim 13, wherein, Providing the rejection signal includes providing the rejection signal to the second integrated circuit via the communication channel.

16. The method according to claim 13, wherein, Providing the rejection signal includes providing the rejection signal to the second integrated circuit via a configurable direct connection separate from the communication channel.

17. A system comprising: communication channel; as well as A first integrated circuit, communicatively coupled to a second integrated circuit via the communication channel, wherein the first integrated circuit is configured to: The assertion signal received from the second integrated circuit via the communication channel indicates that the second integrated circuit requests control over one or more resources shared between the first integrated circuit and the second integrated circuit for a period of time. In response to receiving the assertion signal, the one or more resources requested by the second integrated circuit are released; as well as Upon detecting a scheduling event, a computational operation utilizing the one or more resources is initiated.

18. The system according to claim 17, wherein, In order to release the one or more resources, the first integrated circuit is further configured to perform at least one of the following: Disable one or more radio frequency (RF) paths; Switching from using the first antenna to using the second antenna; and Modify the transmit power of the first integrated circuit.

19. The system according to claim 17, wherein, In order to release the one or more resources, the first integrated circuit is further configured to release the one or more resources for a predetermined period of time.

20. The system according to claim 17, wherein, The scheduling event includes determining that the first integrated circuit has a scheduled computational operation, the scheduled computational operation having a scheduling priority that satisfies a threshold priority.

21. A first integrated circuit, comprising: An interface circuit configured to communicate with a second integrated circuit via a communication channel in an electronic device; as well as Processor circuitry, the processor circuitry being configured to: An authorization request related to authorization to perform activities on the third integrated circuit is received via a configurable direct connection separate from the communication channel. At least in part in response to the received authorization request, it is determined whether the third integrated circuit is authorized to perform the activity, and In response to the determination, a response signal is sent to the third integrated circuit via the configurable direct connection.

22. The first integrated circuit according to claim 21, wherein, The processor circuit is further configured as follows: Within the time limit, internal arbitration is performed to determine whether the third integrated circuit is authorized to perform the activity; as well as Within the time limit, the response signal is sent to the third integrated circuit via the configurable direct connection based on the internal arbitration.

23. The first integrated circuit according to claim 21, wherein, The received authorization request is further related to access to resources of the first integrated circuit for performing the activity, and the processor circuit is further configured to: In response to the determination, an grant signal or a denial signal is sent to the third integrated circuit via the configurable direct connection to grant or deny access to the resource to the third integrated circuit.

24. The first integrated circuit according to claim 23, wherein: The interface circuit is further configured to receive information from the second integrated circuit via the communication channel regarding the availability of the resource within a predetermined time period; as well as In response to the received availability information, the processor circuitry is further configured to send the grant signal or the rejection signal to the third integrated circuit via the configurable direct connection.

25. The first integrated circuit according to claim 21, wherein, The processor circuit is further configured as follows: Receive information about the priority and duration of the activity from the third integrated circuit via the configurable direct connection; and Whether the third integrated circuit is authorized to perform the activity is determined in part based on the received information.

26. The first integrated circuit according to claim 21, wherein, The received authorization request is further related to access to resources shared by the first integrated circuit and the third integrated circuit, and the processor circuit is further configured to: In response to the determination, an grant signal or a denial signal is sent to the third integrated circuit via the configurable direct connection to grant or deny access to the shared resource to the third integrated circuit.

27. The first integrated circuit according to claim 26, wherein: The interface circuit is further configured to receive information from the second integrated circuit via the communication channel regarding the availability of the shared resource within a predetermined time period; as well as The processor circuitry is further configured to send the grant signal or the rejection signal to the third integrated circuit via the configurable direct connection in response to the received availability information.

28. The first integrated circuit according to claim 21, wherein: The interface circuitry is further configured to coordinate the activity with the second integrated circuit via the communication channel within a time constraint; and The processor is further configured to: Within the stated time limit, conduct internal arbitration regarding the activity. Within the stated time limit, based on the coordination and internal arbitration, it is determined whether the third integrated circuit is authorized to perform the activity, and After the time limit, based on the determination, the response signal is sent to the third integrated circuit via the configurable direct connection.

29. The first integrated circuit according to claim 28, wherein, The response signal includes an grant signal or a denial signal, used to grant or deny the third integrated circuit access to the resource for performing the activity.

30. The first integrated circuit according to claim 28, wherein, The response signal includes a configuration signal for configuring at least one resource to a new state preferred for the activity requested by the third integrated circuit, the at least one resource being shared by the first integrated circuit and the third integrated circuit.

31. A method for coordinating the operation of electronic components in an electronic device at a first integrated circuit of the electronic device, the method comprising: Communicating with the second integrated circuit via a communication channel in the electronic device; An authorization request related to an authorization to perform an activity on the third integrated circuit is received via a configurable direct connection separate from the communication channel. At least in part in response to the received authorization request, determine whether the third integrated circuit is authorized to perform the activity; as well as In response to the determination, a response signal is sent to the third integrated circuit via the configurable direct connection.

32. The method of claim 31, further comprising: Within the time limit, internal arbitration is performed to determine whether the third integrated circuit is authorized to perform the activity; as well as Within the time limit, the response signal is sent to the third integrated circuit via the configurable direct connection based on the internal arbitration.

33. The method according to claim 31, wherein, The received authorization request is further related to access to resources of the first integrated circuit for performing the activity, and the method further includes: In response to the determination, an grant signal or a denial signal is sent to the third integrated circuit via the configurable direct connection to grant or deny access to the resource to the third integrated circuit; Receive information from the second integrated circuit via the communication channel regarding the availability of the resource within a predetermined time period; and In response to the received availability information, the grant signal or the rejection signal is sent to the third integrated circuit via the configurable direct connection.

34. The method of claim 31, further comprising: Information regarding the priority and duration of the activity is received from the third integrated circuit via the configurable direct connection; as well as Whether the third integrated circuit is authorized to perform the activity is determined in part based on the received information.

35. The method of claim 31, further comprising: Within the time limit, the activity is coordinated with the second integrated circuit via the communication channel; Within the stated time limit, conduct internal arbitration regarding the activity; Within the time limit, based on the coordination and the internal arbitration, it is determined whether the third integrated circuit is authorized to perform the activity; as well as After the time limit, based on the determination, the response signal is sent to the third integrated circuit via the configurable direct connection.

36. The method according to claim 35, wherein, Sending the response signal also includes: Send an grant or deny signal to the third integrated circuit via the configurable direct connection to grant or deny access to resources for performing the activity.

37. The method of claim 35, wherein, Sending the response signal also includes: A configuration signal is sent to the third integrated circuit via the configurable direct connection to configure at least one resource to a new state preferred for the activity requested by the third integrated circuit, the at least one resource being shared by the first integrated circuit and the third integrated circuit.

38. An electronic device comprising: communication channel; as well as A first integrated circuit, connected to a second integrated circuit via the communication channel and connected to a third integrated circuit via a configurable direct connection separate from the communication channel, wherein the first integrated circuit is configured to: The system receives an authorization request from the third integrated circuit via the configurable direct connection. The authorization request relates to an authorization to perform activities on the third integrated circuit. At least in part in response to the received authorization request, it is determined whether the third integrated circuit is authorized to perform the activity, and In response to the determination, a response signal is sent to the third integrated circuit via the configurable direct connection.

39. The electronic device according to claim 38, wherein, The first integrated circuit is further configured as follows: Within the time limit, internal arbitration is performed to determine whether the third integrated circuit is authorized to perform the activity; and Within the time limit, the response signal is sent to the third integrated circuit via the configurable direct connection based on the internal arbitration.

40. The electronic device according to claim 38, wherein, The first integrated circuit is further configured as follows: Within the time limit, the activity is coordinated with the second integrated circuit via the communication channel; Within the stated time limit, conduct internal arbitration regarding the activity; Within the time limit, based on the coordination and the internal arbitration, it is determined whether the third integrated circuit is authorized to perform the activity; as well as After the time limit, based on the determination, the response signal is sent to the third integrated circuit via the configurable direct connection.

Images