Bulletin board for contextual information sharing

Abstract

The invention relates to a bulletin board for contextual information sharing. Embodiments relate to a bulletin board circuit (326) that stores contextual information received from various component circuits in an electronic device. The contextual information indicates an operating state of the corresponding component circuitry, system, or shared resource. When an event (e.g., turning on of the component circuitry) is detected, the stored contextual information may be retrieved by the one or more component circuitry. By using the bulletin board circuit, the component circuit can detect a change in the operating state of other component circuits, and can configure or update its operation even when a change occurs while the component circuit is sleep or disabled. The bulletin board circuitry may monitor updates of the contextual information through the component circuitry and initiate notifications to other component circuitry when certain entries of the contextual information are updated.

Description

[0001] This application is a divisional application of the invention patent application with application date of December 10, 2020, application number 202080094822.4, and invention name “Bulletin board for sharing contextual information”. Technical Field

[0002] The present disclosure relates to coordinated operation of multiple integrated circuit (IC) chips in electronic devices. Background Art

[0003] An electronic device may include multiple systems on a chip (SOCs) for communicating with other devices using various communication protocols. As the size of communication systems in electronic devices decreases while the functionality of communication systems increases, more SOCs are incorporated into electronic devices, or more subsystems are added to each SOC. These SOCs can communicate with a host (e.g., a central processing unit or an application processor) through a dedicated communication path (e.g., a peripheral component express interconnect (PCIe)) to transfer data.

[0004] As a result of integrating multiple communication systems and other subsystems into electronic devices, various problems or complications may arise. These problems or complications include conflicts and constraints imposed by using a shared communication channel (such as a multi-drop bus between the SOC and the subsystems). Summary of the invention

[0005] Embodiments relate to an electronic device that includes a notice board circuit that stores context information about an integrated circuit. The context information indicates an operational state of the integrated circuit. The context information may be sent from the integrated circuit to the notice board circuit via a multi-drop bus at a first time for storage in the notice board circuit. The context information may be retrieved from the notice board circuit and sent to another integrated circuit at a second time later than the first time after an event is detected. The other integrated circuit may change its operation in response to receiving the context information. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 is a high-level diagram of an electronic device according to one embodiment.

[0007] Figure 2 is a block diagram illustrating components in an electronic device having multiple systems according to one embodiment.

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

[0009] Figure 4A According to an implementation scheme Figure 3 Block diagram of a scheduler in a coexisting hub device.

[0010] Figure 4B is a block diagram of a notice board in a coexistence hub device according to one embodiment.

[0011] Figure 5 is a block diagram of a SOC in communication with a notice board according to one embodiment.

[0012] Figure 6 is a block diagram of an application processor and system in an electronic device according to one embodiment.

[0013] Figure 7 is a flow chart illustrating a process for operating a notice board according to one embodiment.

[0014] For purposes of illustration only, the Brief Description of the Drawings and the Detailed Description describe various non-limiting embodiments. DETAILED DESCRIPTION

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

[0016] Embodiments relate to a notice board circuit that stores context information received from various component circuits in an electronic device. The context information indicates the operating state of the corresponding component circuit, system, or shared resource. When an event (e.g., the activation of a component circuit) is detected, the stored context information can be retrieved by one or more component circuits. By using the notice board circuit, the component circuit can detect changes in the operating state of other component circuits, and can configure or update its operation even when changes occur while the component circuit is asleep or disabled. The notice board circuit can monitor updates to the context information by the component circuit, and when certain items of the context information are updated, notifications to other component circuits are initiated.

[0017] Exemplary Electronic Devices

[0018] Embodiments of electronic devices, user interfaces for such devices, and associated processes for using such devices are described herein. In some embodiments, 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 a music player function. Exemplary embodiments of portable multifunction devices include, but are not limited to, the Apple Watch from Apple Inc. (Cupertino, California). equipment, equipment, Equipment and Device. Other portable electronic devices, such as wearable devices, laptops, or tablet computers may alternatively be used. In some embodiments, the device is not a portable communication device, but rather 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 touch screen display and / or a touchpad). Figure 1 The described example electronic device (eg, 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.

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

[0020] In some embodiments, the device 100 includes a touch screen 150, a menu button 104, a push button 106 for turning the device on / off and for locking the device, a volume adjustment button 108, a subscriber identity module (SIM) card slot 110, an earphone jack 112, and a docking / charging external port 124. The push button 106 can be used to turn the device on and off by pressing the button and keeping the button pressed for a predefined time interval; lock the device by pressing the button and releasing the button before the predefined time interval passes; and / or unlock the device or initiate an unlocking process. In an alternative embodiment, the device 100 also accepts voice input for activating or deactivating certain functions through a microphone 113. The device 100 includes various components, including but not limited to a memory (which may include one or more computer-readable storage media), a memory controller, one or more central processing units (CPUs), a peripheral device interface, an RF circuit, an audio circuit, 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 facial recognition. Additionally or alternatively, 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 in the figure, such as an ambient light sensor, a dot projector, and a flood illuminator.

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

[0022] Exemplary communication system in an electronic device

[0023] Figure 2 1 is a block diagram showing components of an electronic device 100 according to one embodiment. The electronic device 100 may include components such as an application processor 208 (also referred to herein as a "central processor"), systems 210A to 210C (collectively referred to herein as "system 210"), a multi-drop bus 220, and structures 222A to 222N. The electronic device 100 may include Figure 2 Other components not shown, such as power conditioning circuits and radio components (e.g., power amplifiers).

[0024] Each system in the system 210 performs a different function in the electronic device 100. For example, the system 210A performs a function of displaying an image on the touch screen 150, the system 210B performs a function of determining the position of the electronic device 100, and the system 210C performs a function of communicating with an external device. Each system in the system 210 may include one or more component circuits in the form of an SOC (e.g., an integrated circuit). The electronic device 100 may include Figure 2 The system 210 may be directly connected to the multi-point bus 220 (e.g., as shown in systems 210B, 210C) or indirectly coupled to the multi-point bus 220 via another component (e.g., as shown in system 210A that communicates with the multi-point bus 220 via an application processor 208).

[0025] The application processor 208 is a processing circuit in the electronic device 100 for performing various operations. The application processor 208 may include one or more processing cores for executing various software programs and dedicated hardware circuits for performing professional functions, such as processing images, performing security operations, performing machine learning operations, and processing audio signals. The application processor 208 may also perform operations to coordinate the operations of other components in the electronic device 100, including the coexistence hub device 212 and the SOC 234. The application processor 208 can operate in a variety of power modes, including a low power mode in which the application processor 208 shuts down most of its components to save power consumption 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. In one or more embodiments, the application processor 208 relays data between components connected by the multi-point bus 220 in a low power mode. To this end, the application processor 208 can (i) receive signals from a device (e.g., the SOC 234, the sensor device 216, and the coexistence hub device 212) via the multi-drop bus 220, (ii) modify or copy the received signals according to predetermined rules, and (iii) send the modified signals to another device (e.g., the SOC 234, the sensor device 216, and the coexistence hub device 212) via the multi-drop bus 220 to enable the SOC 234 to communicate effectively.

[0026] Figure 2 2 , an example system 210C is shown that includes a coexistence hub device 212 (also referred to herein as a “coexistence hub device”) and SOCs 234A through 234N (collectively referred to herein as “SOC 234”). SOC 234 and coexistence hub device 212 may communicate via a multi-drop bus 220.

[0027] Coexistence hub device 212 is a circuit or a combination of circuit and software that coordinates the operation of the associated components in system 210C (including, for example, coexistence hub device 212 and SOC 234) and electronic device 100. For this purpose, coexistence hub device 212 stores and executes an operation strategy for defining and / or coordinating the operation of communication system and associated components. Operation strategy can be, for example, based on factors such as the operating conditions of system 210C, the time length of the communication subsystem remaining in the waiting state, the power consumption of each communication subsystem, and the condition of the channel used by the communication subsystem to determine the real-time operation of components in system 210C. Based on operation strategy, coexistence hub device 212 performs operation in advance to set or prepare the communication subsystem to activate or deactivate, so that the activation or deactivation of the communication subsystem occurs without any error. In one or more embodiments, coexistence hub device 212 includes one or more subsystems that perform communication operations through various physical interfaces. By performing such coexistence operations locally at system 210C, application processor 208 can continue to operate in a low power mode for a longer period of time regardless of activity in system 210C, and also free up resources of application processor 208 during its high power mode. Figures 3 to 4B The details of the coexistence hub device 212 are described in detail.

[0028] In an example where system 210C is responsible for communicating with external devices, each of the SOCs 234 may be a circuit, alone or in combination with software or firmware, that performs operations for communicating with one or more external networks or devices using a communication protocol or a security protocol. Each of the SOCs 234 and the coexistence hub device 212 may process different communication protocols and / or be associated with different wireless frequency bands. For example, SOC 234A may perform processing for long-range communications (e.g., cellular communications) while SOC 234B or the coexistence hub device 212 processes short-range communications (e.g., Bluetooth communications). Another example is sharing lower-level circuit components 250 (e.g., power amplifiers) by different SOCs 234. The operations of the SOCs 234 (e.g., using a communication protocol, wireless frequency band, or power amplifier) ​​are at least partially controlled by the coexistence hub device 212. Reference is made below to Figure 5 An example of SOC 234B is described in detail.

[0029] Fabric 222 is a communication channel that enables components in the communication system to communicate with application processor 208. One or more of fabrics 222 may be embodied as a point-to-point connection, such as a peripheral component interconnect express (PCIe), I2C, or a serial peripheral interface (SPI). Figure 2As shown, SOC 234A, coexistence hub device 212, and SOCs 234B through 234N communicate with application processor 208 via corresponding fabrics 222A through 222N. One or more of fabrics 222 may have high bandwidth and low latency compared to multi-drop bus 220. Figure 2 The structure 222 shown in may be a physically separate communication channel or one or more shared physical channels with multiple logical sub-channels.

[0030] The multi-point bus 220 is a communication channel that enables multiple components of the same system or different systems to communicate through a shared connection. The multi-point bus 220 can be mainly used to transmit various messages, including but not limited to data packets, timing packets, and coexistence messages between components in the communication system. The data packets described herein refer to messages including data processed by devices or systems (such as SOC 234 and coexistence hub devices 212) that communicate through the multi-point bus 220. The timing packets described herein refer to messages indicating the time when a periodic event occurs at one of the SOC 234 or the coexistence hub device 212. Coexistence messages refer to messages for coordinating operations between SOC 234 and coexistence hub devices 212 or between subsystems of a shareable common component (e.g., power management unit (PMU), power amplifier (PA), or low noise amplifier (LNA)) on a pair of SOCs 234. These coexistence messages can be used to enable two communication subsystems with conflicting operating requirements to operate at an acceptable performance level when a conflict situation is active. Some coexistence messages may include context information or programming information for components (e.g., PA and LNA) to be shared between systems to achieve compatibility between the systems. In one or more embodiments, a system power management interface (SPMI) is used to embody the multi-drop bus 220. Other serial bus interfaces such as I2C may be used instead of SPMI to embody the multi-drop bus 220. Although Figure 2 Only a single multi-drop bus 220 is shown in FIG. 1 , but two or more multi-drop buses may be used.

[0031] One or more of the systems 210 may include a general purpose input / output (GPIO) that interfaces with a SOC in the system to provide context information indicating that the multi-drop bus 220 or fabric 222 is not operational due to issues such as low power levels. For example, when the coexistence hub device 212 detects that the multi-drop bus 220 is not operating, the coexistence hub device 212 may send context information to the SOC 234A via the GPIO 242 to indicate such an event. Figure 2Only a single GPIO 242 is shown in FIG. 2 , but more GPIOs may be provided between the coexisting hub device 212 and the other SOCs 234B to 234N or even between other systems (eg, system 210B).

[0032] In one or more embodiments, a system (e.g., system 210C) may include shared resources, such as shared components (e.g., component 250). Shared component 250 may be, for example, a lower level circuit component, such as a power amplifier. Shared component 250 may be shared by different SOCs 234, for example, in a time multiplexing manner. Contextual information related to the operation or sharing of such shared components 250 may be stored in coexistence hub device 212 and / or SOC 234B. In another example, shared component 250 may use other multiplexing schemes (e.g., frequency multiplexing) to enable multiple SOCs to perform their operations simultaneously.

[0033] Despite Figure 2 Not shown, the coexistence hub device 212 may also control operation of or access to one or more antennas (not shown) associated with the communication system.

[0034] Example Architecture of Coexisting Hub Devices

[0035] Figure 3 2 is a block diagram illustrating a coexistence hub device 212 according to one embodiment. The coexistence hub device 212 coordinates the operations of the components in the system 210C. The coexistence hub device 212 may also handle operations that are different from or partially overlap with the operations performed by the SOC 234. In the following, the coexistence hub device 212 is described primarily with reference to the system 210C performing communications with external devices. However, this is merely an example, and the system 210C may be associated with other multi-SOC systems such as display devices, power management circuits, and global positioning system (GPS) systems.

[0036] To perform its operations, the coexistence hub device 212 may include a processor 304, a coexistence control circuit 314, a fabric interface 310, a multipoint interface 340, communication subsystems 336A through 336Z (collectively referred to as "communication subsystems 336"), a GPIO interface 390, and an internal structure 342, among other components. The coexistence hub device 212 may include Figure 3 Additional components not shown or may be omitted Figure 3 Components shown in (eg, one or more of communication subsystems 336 ).

[0037] The processor 304 is a circuit, alone or in combination with software or firmware, that controls the overall operation of the coexistence hub device 212 and the coordinated operation of other SOCs 234 using coexistence messages. The processor 304 may include memory to store an operating policy 352 for controlling operation. The operating policy 352 may be received from the application processor 208 via the fabric 222B, the fabric interface 310, and the internal fabric 342. After receiving the operating policy 352, the processor 304 may decode the operating policy 352 and, if applicable, program other components in the coexistence hub device 212 (e.g., the coexistence control circuit 314) to execute the operating policy 352. Additional information related to the operating policy 352 may also be received from the application processor 208. Such additional information may be stored or processed at the processor 304 to affect the implementation of the operating policy 352. In addition, the processor 304 may send a portion of the operation policy 352 related to the other SOC 234 via the multi-drop bus 220 to program the SOC 234 to operate according to the operation policy 352. The processor 304 may make coexistence decisions according to the operation policy 352 by analyzing the coexistence messages (e.g., context information or requests) received from the SOC 234 and the communication subsystem 336 via the interface 340. The processor 304 may store the status 354 (e.g., context information) of the communication subsystem 336 and other SOCs 234 in the coexistence hub device 212. The current status 354 may include, for example, the radio frequency (RF) band / channel used by the SOC 234 and the coexistence hub device 212, the transmission power of the radio signal. Such information may also be sent to the application processor 208 or other SOCs 234 to enable real-time adjustment of operations in other SOCs 234. The processor 304 may delegate some coordination operations (e.g., coordination of the communication subsystem 336) to the arbitrator 322.

[0038] As described herein, an operation policy refers to a scenario of a combination of operations in a communication system that may be problematic or a combination of components having interworking problems, and also refers to a set of rules that define actions to be taken by the SOC 234 and the coexistence hub device 212 to resolve or handle such problematic scenarios. In some embodiments, the operation policy may include firmware code and enable dynamic responses to maintain balanced operations between multiple communication subsystems.

[0039] Each of the communication subsystems 336 includes circuitry for processing signals received from or sent to a corresponding physical layer interface 308A to 308Z (collectively, “physical layer interface 308”) external to the coexistence hub device 212. Such circuitry may include a local processor 378A to 378Z (collectively, “local processor 378”) that performs one or more of the following operations: (i) executes commands associated with certain communication protocols, (ii) processes received incoming communication signals according to the corresponding protocol to decode the incoming radio signal and respond by encoding certain responses within a required time budget on the RF link, (iii) controls the associated radio frequency (RF) path to adjust transmit power or receive gain control, and (iv) configures, disables, or enables components in the communication subsystem 336 based on an operating policy. When the coexistence hub device 212 is initialized, all or at least a subset of these local processors 378 may be initialized (e.g., by the application processor 208 or automatically). Among other things, the local processor 378 is programmed with a portion of the operating policy related to the operation of its communication subsystem 336. The operating policy of the local processor 378 downloaded to the communication subsystem 336 may define how the communication subsystem 336 should operate (e.g., the data rate of the communication subsystem, turning components in the communication subsystem 336 on or off, and changing the number of active transmitters). Alternatively, as each of the communication subsystems 336 is turned on, the relevant portion of the operating policy may be sequentially downloaded and programmed directly by the application processor 208 through the structure 222B or by the processor 304. One or more of the communication subsystems 336 may communicate with a physical layer interface (e.g., RF device) via, for example, a radio frequency front end control interface (RFFE).

[0040] In some embodiments, the physical layer interface 308 can be consolidated into a reduced set, where the local processor 378 supports more than one communication protocol or switches between different communication protocols over time. The local processor 387 can control a fixed set of radio paths or only the front-end switches, and the LNA or PA can be controlled by the physical layer interface 308.

[0041] The interface 340 is a circuit or a combination of circuits and software for communicating with the multi-drop bus 220. In one or more embodiments, the interface 340 includes circuit components for processing data into outbound packets for transmission over the multi-drop bus 220 and deaggregating inbound packets received from the multi-drop bus 220 into data for processing in the coexistence hub device. The interface 340 is connected to the processor 304 and the coexistence control circuit 314 via connection 328.

[0042] The fabric interface 310 is a circuit or a combination of circuits and software for enabling the coexistence hub device 212 to communicate with the application processor 208 via the fabric 222B. The fabric interface 310 is also referred to herein as an internal communication channel. In one or more embodiments, the fabric interface 310 performs operations such as buffering, splitting / assembling data, serializing / deserializing, and packing / unpacking data for communication via a point-to-point communication channel (e.g., PCIe). Figure 3 As shown, the fabric interface 310 is connected to the internal fabric 342 to enable communication between components in the coexistence hub device 212 and the application processor 208 .

[0043] The coexistence control circuit 314 is a circuit alone or in combination with software that processes coexistence messages transmitted over the multi-drop bus 220. The coexistence control circuit 314 is programmed by the processor 304 to execute the operating policy 352 by making real-time decisions on coexistence events, publishing inbound coexistence messages to relevant communication subsystems 336, sharing real-time coexistence messages between communication subsystems 336, and sending outbound coexistence messages to other SOCs 234. Coexistence events, as described herein, refer to conditions or occurrences defined by the operating policy that will prompt coordination of operations among the components of the electronic device 100.

[0044] Specifically, the coexistence control circuit 314 may include a scheduler 312, a memory 316, an arbitrator 322, and a notice board 326, among 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. Figure 4A Details of the scheduler 312 and its functions are described.

[0045] The memory 316 has a plurality of buffers 318A to 318Z (collectively referred to as "buffers 318"), each of which corresponds to each of the communication subsystems 336. Each of the buffers 318 receives and stores inbound messages associated with the corresponding communication subsystem 336 (received from components external to the coexistence hub device 212 via the multipoint bus 220). The inbound coexistence messages stored in the buffers 318 can be sent to the corresponding communication subsystem 336 (as shown by arrow 372) via the internal structure 342 based on priority (e.g., time-sensitive data has a higher priority than time-insensitive data). If one or more communication subsystems 336 are inactive, the buffers 318 store the messages until the communication system 336 is turned on and becomes available to receive the messages. In one or more embodiments, different buffers 318 can be associated with different priorities. When a buffer assigned a high priority is filled with a message, the communication system 336 can wake up to serve to ensure that the message is processed in a timely manner. Each of the buffers 318 also stores outbound messages 348 (received from the corresponding communication subsystem 336 via the internal structure 342). The outbound messages are retrieved by the scheduler 312 and are also sent to components external to the coexistence hub device 212 via the multi-drop bus 220 based on priority (e.g., time-sensitive data has a higher priority than time-insensitive data).

[0046] The memory 316 also includes a shared memory portion 320 that is accessible by an arbiter 322 to resolve conflicting uses of resources and by different local processors 378 to exchange time-sensitive messages between the communication subsystems 336. The communication subsystems 336 can submit their tasks along with requests from other SOCs 234 to a memory queue to be serviced by the arbiter 322.

[0047] The notice board 326 is a circuit alone or in combination with software or firmware that stores context information of: (i) other SOCs in the same system (e.g., SOCs 234A to 234N), (ii) SOCs in other systems (e.g., systems 210A, 210B), and / or (iii) subsystems 336 within the coexisting hub device 212. Context information from other systems or SOCs in system 210C is received via the multi-drop bus 220 using interface 340 and connection 328. The received context information is received by the scheduler 312, which sends the context information to the notice board 326, if applicable. Context information 346 is received from the communication subsystem 336 and stored in the notice board 326 for access. In addition to the context information, the notice board 326 may also store a subset of the data packets transmitted over the multi-drop bus 220. Such data packets may be available to other SOCs that are, for example, in a sleep state and are unable to receive the data packets when they are transmitted by the source SOC.

[0048] The stored context information may then be used to trigger one or more operations on the coexistence hub device 212 or other SOCs that later receive the stored context information. The notice board 326 enables external systems (e.g., systems 210A and 210B), SOCs in system 210C, and / or components in the coexistence hub device 212 (e.g., communication subsystem 336) to accurately determine the operational context of other systems, SOCs, or components by accessing the context information in the notice board 326. The context information may be sent from the coexistence hub device 212 directly to an external system, SOC, and / or component in the same system 210C via the multi-drop bus 220 or GPIO 242. Alternatively, the context information may be sent to a first recipient (e.g., a system, SOC, and / or component), processed (e.g., filtered or converted) at the first recipient, and then the processed version of the context information is sent to a second recipient (e.g., another system, another SOC, and / or another component). Even if a subset or all of the other external systems, SOCs, or communication subsystems are shut down and unavailable to provide context information, the most recent context information is stored and available for retrieval and access by other systems, other SOCs, or components of the coexistence hub device 212. Figure 4B The example structure and function of the notice board 326 are described in detail. The notice board can also be used to transmit the current state of another SOC to the receiving SOC, regardless of the radio sleep state of the receiving SOC. This allows external systems to update the sleep system of some key states.

[0049] The arbitrator 322 is a circuit, alone or in combination with software or firmware, that makes decisions regarding the real-time coordination of the operation of the communication subsystem 336 and sends the decisions to the communication subsystem 336 through the internal structure 342 and the memory 316. Such decisions may include resolving competing demands for common resources by multiple communication subsystems 336 or requests for incompatible resources by different communication subsystems 336. The arbitrator 322 makes decisions in real time and may remain valid for a shorter period of time than decisions made at the processor 304 to implement the operating policy 352. In addition, the arbitrator 322 may resolve requests for resource use by external communication subsystems that compete with the local communication subsystem 336 for the use of the same resources. For this purpose, the arbitrator 322 may access the current state 354 of the communication subsystem 336 and other SOCs 234 stored in the processor 304 and use information about the priority of different competing operations. The algorithm for resolving resource conflicts at the arbitrator 322 may be adjusted based on the operating policy 352 executed by the processor 304. The arbitrator 322 may be programmed by the processor 304 or the application processor 208. Decisions made by the arbitrator 322 may include, for example, controlling RFFE transactions associated with the communication subsystem 336 to change settings of external RF devices. Such operations may include blanking power amplifier transmissions of the corresponding communication subsystem 336. Because real-time decisions are issued through the shared internal structure 342, a communication subsystem (e.g., communication subsystem 336A) can receive decisions intended for another communication subsystem (e.g., communication subsystem 336B) and adjust its operations accordingly. The arbitrator 322 may include a processor 323 to control the overall operation of the arbitrator 322.

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

[0051] GPIO interface 390 is circuitry that enables other SOCs (eg, SOC 234A) to communicate with components of coexisting hub device 212 via GPIO 242 .

[0052] Figure 3 The components of the coexistence hub device 212 shown in FIG. 2 are merely illustrative. The coexistence hub device 212 may include fewer components (e.g., lacking the memory 316 or a separate processor 304) or include Figure 3 Additional components not shown (e.g., general purpose input / output).

[0053] Example architecture of the scheduler

[0054] Figure 4A According to an implementation scheme Figure 3 2. Block diagram of a scheduler 312 in a coexistence hub device of FIG. The scheduler 312 is a circuit or a combination of circuits, software and / or firmware for processing messages. The scheduler 312 determines when an outbound message from the communication subsystem 336 should be sent to the processor 304 or SOC 234, and when the time arrives, the outbound message is forwarded to the interface 340 for sending through the multi-point bus 220. The time for sending the outbound message is based on the priority of the outbound message (whether or not other messages are retained in the memory 316 for sending through the multi-point bus 220) and when the arbitration for transmitting data using the multi-point bus 220 is successful. The scheduler 312 also receives messages from the SOC 234 through the multi-point bus 220 and forwards the messages to the communication subsystem 336 through the internal structure 342.

[0055] The scheduler 312 may include, among other components, a processor 436, an interrupt manager 428, a timestamp 440, and a message filter 432. One or more of the interrupt manager 428, the timestamp 440, and the message filter 432 may be embodied as firmware of software executed by the processor 436. Furthermore, additional components may be added to the scheduler 312.

[0056] Processor 436 is a circuit that can perform various operations in scheduler 312, such as (i) managing competing resources within each communication subsystem 336, (ii) controlling external RF control blocks outside of coexistence hub device 212, (iii) supporting the functions and operations of arbitrator 322, and (iv) coordinating the reporting of results from arbitrator 322 to components on multi-drop bus 220. Processor 436 can be part of processor 304, or it can be a separate processor. Processor 436 can also update the operations of other components in scheduler 312 over time or depending on activities in electronic device 110.

[0057] The message filter 432 is hardware, software, firmware, or a combination thereof that receives inbound messages 422 from the multi-drop bus 220 via the interface 340, filters the inbound messages 422 for association with the notice board 326 and the communication subsystem 336, and sends the filtered inbound messages 454 to the appropriate buffer 318 and / or shared portion 320 of the memory 316 and the context information 346 to the notice board 326. The message filter 432 may also redirect the inbound messages 454 to buffers associated with communication subsystems 336 other than the default communication subsystem 336 to ensure that the active communication subsystem 336 receives all relevant inbound messages. By configuring the message filter 432, a communication subsystem (e.g., 336A) may receive inbound messages that are also intended for another communication subsystem (e.g., 336B) and consider such inbound messages for its operation. If the inbound message includes an interrupt, the message filter 432 sends the corresponding coexistence message 442 to the interrupt manager 428.

[0058] The interrupt manager 428 is hardware, software, firmware, or a combination thereof that manages interrupts. When the interrupt manager 428 receives a coexistence message 442 including an interrupt, the interrupt manager 428 extracts the interrupt and sends an interrupt signal 414 to the corresponding communication subsystem 336. The interrupt signal 414 can shut down the corresponding communication subsystem 336, power down a subset of its components, wake up from a power-down mode, or indicate the real-time status of a component (e.g., SOC 234) on the multi-drop bus 220. These interrupt signals can involve only a simple decoder and no microprocessor, which enables low-cost components to send interrupt signals to transmit simple messages through the multi-drop bus 220. One of the characteristics of interrupt signals is that they are sticky, which means that even if the SOC (e.g., SOC 234B) is in a sleep state or disabled when the coexistence hub device 212 sends the interrupt signal, the SOC (e.g., SOC 234B) will respond to the interrupt signal after the SOC (e.g., SOC 234B) wakes up at a later time. These interrupt signals can also be used to ensure that an external SOC (e.g., SOC 234B) can suddenly go to an inactive state / sleep state without requiring other components (e.g., SOC 234A) to stay awake long enough to complete handshake operations with the SOC (e.g., SOC 234B). By using always-on interrupt signals, the burden on the source of the initiating message can be reduced.

[0059] The message filter 432 may also receive an interrupt signal 450 from the communication subsystem 336. If the interrupt signal 450 is intended for the SOC 234, the message filter 432 sends the interrupt signal 450 as an outbound coexistence message 418 to the interface 340 for transmission via the multi-drop bus 220. Interrupt signals between the communication subsystems 336 are transmitted through the internal structure 342 without intervention by the coexistence control circuit 314.

[0060] Timestamp 440 is circuitry that tracks the time of incoming and outgoing messages on multi-drop bus 220 .

[0061] Example architecture of a notice board

[0062] Figure 4B 4 is a block diagram illustrating a notice board 326 according to one embodiment. The notice board 326 may include other components such as a security check circuit 462, a status check circuit 464, a memory access circuit 466, a notification circuit 480, and a memory 468. The notice board 326 may include additional components or Figure 4B Fewer components. For example, the safety check circuit 462 and / or the status check circuit 464 may be omitted.

[0063] The security check circuit 362 is hardware or a combination of hardware and software that determines whether the SOC or device requesting to write context information or the SOC or device requesting to read stored context information is authorized to access the memory 468. To do this, the security check circuit 362 may determine whether the device address and security code included in the write / read request from the SOC or device match the corresponding entry in the memory 468. If the device address and security code match, the security check circuit 362 enables the memory access circuit 466 to read the context information from the memory 468 or write the context information to the memory.

[0064] The status check circuit 464 is hardware or a combination of hardware and software that determines whether a SOC or device in an external system (e.g., system 210A, 210B) or within the same system (e.g., system 210C) is currently active or inactive. The status check circuit 464 can receive periodic heartbeat messages from the SOC or device and perform operations such as updating and / or locking the context information of the corresponding SOC or device stored in the memory 468. The status check circuit 464 can also implement a mechanism to ensure that the context information stored in the memory 468 is the most recent. The notice board can also support a mechanism to alert the communication system within the updated SOC.

[0065] Memory access circuitry 466 is hardware or a combination of hardware and software that enables context information to be read from or written to memory 468. In one or more embodiments, memory access circuitry 466 performs an operation to write or read context data when security check circuitry 462 authorizes the read or write operation.

[0066] The notification circuit 480 is hardware or a combination of hardware or software that tracks updates in the context information in the memory 468 and sends notifications to the communication subsystem 336, SOC 234, or system 210B. To this end, notification requests from the communication subsystem 336, SOC 234, and / or system 210B can be registered in the notification circuit 480 for certain events or conditions. The notification circuit 480 monitors changes in entries or fields in the memory 468. When changes in entries or fields in the memory 468 correspond to certain events or conditions, the notification circuit 480 sends notifications or context information to the registered communication subsystem 336, SOC 234, or system 210B through the multi-drop bus 220, the fabric 222B, or the GPIO 242.

[0067] In one or more embodiments, notification circuitry 480 may update or process context information in memory 468 before sending it to the communication subsystem 336, SOC 234, or system 210B. Notifications or context information sent to a registered communication subsystem 336, SOC 234, or system 210B may be processed at the communication subsystem 336, SOC 234, or system 210B and sent to other subsystems, SOCs, or systems.

[0068] The memory 468 stores context information received from the SOCs and / or devices in the various systems 210. The context information of one SOC or device in a system (e.g., system 210B) may be accessed by other SOCs or devices in other systems (e.g., system 210A) upon request. Thus, when the SOCs or devices in other systems (e.g., system 210A) are placed in sleep mode and then become active, the SOCs or devices in other systems (e.g., system 210A) may access the memory 468 to receive context information of other SOCs or devices in the system (e.g., system 210B) that may have changed while the SOCs or devices of the system (e.g., system 210A) were in sleep mode. Similarly, a SOC in the same system (e.g., SOC 234A) may receive context information of another SOC (e.g., SOC 234B) that may have changed while the SOC (e.g., SOC 234A) was in sleep mode.

[0069] The memory 468 may also store a subset of the data packets 492 transmitted over the multi-drop bus 220. These data packets 492 may be accessed and retrieved by the SOC 234 or other components of the coexistence hub device 212. In some cases, the new data packets replace the corresponding outbound data packets, while in other cases both the old data packets and the new data packets are retained in the memory 468 for later retrieval.

[0070] The context information stored in the memory 468 may be associated with other data fields, including but not limited to a device address, a timestamp, and a security code. The device address refers to the physical or logical address of the SOC or device associated with the context information. The timestamp indicates the time when the context information was sent from the corresponding SOC or device or when the context information was received at the coexistence hub device 212. The security code indicates data used to authenticate a read or write request for context information and may be used by the security check circuit 462 to approve or deny a read or write request received at the notice board 326.

[0071] exist Figure 4B In the example of , memory 468 stores context information for a display device in its first entry. The display device uses a device address of 0100-0110 and received its most recent context information at time 11:53:21. The entry includes security code XYZ, and the context information indicates that the display device is in an active awake state and operating at a refresh rate of 60 Hz and a display resolution B. The second entry indicates that the context information is related to a proximity sensor module. Context information was received at time 11:52:26, ​​is associated with security code AYB, and indicates that the sensor is turned on and operating using a local clock running at speed X. The last entry of memory 468 relates to a power control module currently operating in a low power mode. Reference above Figure 4B The explained entries, devices, and context information are illustrative only.Memory 468 may store context information in various other formats and include various other information.

[0072] Example Architecture of a SOC

[0073] Figure 5 is a block diagram of a SOC 234B according to one embodiment. Figure 5 234B is shown as an example, but other SOCs 234A and 234C to 234N may have the same or similar architecture as SOC 234B. SOC 234B may send messages including context information to coexistence hub device 212 or other SOCs via multi-drop bus 220 and / or receive messages including context information from other SOCs of coexistence hub device 212 or other SOCs.

[0074] In examples where system 210C is a communication system, SOC 234B may use its communication subsystems 536A, 536B (collectively, "communication subsystems 536") to execute one or more communication protocols. Figure 5 Only two communication subsystems 536A, 536B are shown in the figure, but more than two communication subsystems or only a single communication subsystem may be included in the SOC 234B. Each of the communication subsystems 536A, 536B may be associated with a different communication protocol, or both may be associated with the same communication protocol. The communication subsystem 536 is substantially the same as the communication subsystem 336 of the coexistence hub device 212, except that messages associated with the communication subsystem 536 are processed by the processor 512 instead of the coexistence control circuit 314. The communication subsystem 536 may send context information to the coexistence hub device 212 via the multi-point bus 220 to achieve coordinated operation with other systems, SOCs and / or coexistence hub devices 212. Inbound messages to the SOC 234B are processed locally by the processor 512 and sent to the corresponding communication subsystem 536. For the sake of brevity, other detailed explanations of the communication subsystem 536 are omitted herein.

[0075] In addition to the communication subsystem 536, the SOC 234B may include a fabric interface 502, a bus interface 504, a processor 512, and an internal bus 540 for connecting these components, among other components. The SOC 234B may include additional components, such as memory for buffering incoming or outgoing messages.

[0076] The bus interface 504 is a circuit, alone or in combination with software or hardware, that enables components of the SOC 234B to communicate with the coexisting hub device 212 and other SOCs via the multi-drop bus 220. The bus interface 540 may perform the same operations as described above with reference to Figure 4B The described interface 340 has the same function and the same structure.

[0077] Fabric interface 502 is circuitry, alone or in combination with software or hardware, that enables components of SOC 234B to communicate with application processor 208 over fabric 222C. Communications over fabric interface 502 can transfer data at faster speeds and higher bandwidths than communications over bus interface 504.

[0078] The processor 512 manages the overall operation of the SOC 234B. The processor 512 may include other components such as an interrupt manager 516, a message filter 518, and a context processor 522 as software or hardware components. The functions and operations of the interrupt manager 516 and the message filter 518 are substantially the same as the functions and operations of the interrupt manager 428 and the message filter 432, and therefore, for the sake of brevity, a detailed explanation of these components is omitted herein.

[0079] Context processor 522 determines the current operating state of SOC 234B and generates context information corresponding to SOC 234B. The context information of SOC 234B may include, for example, the operating mode of SOC 234B (e.g., sleep mode and active mode), the communication frequency of communication subsystem 536A, 536B, and whether any one of its components is disabled or its operation is limited to prevent any coexistence problems. In one or more embodiments, context processor 522 also receives context information of other SOC 234 or other systems (e.g., system 210A, 210B) and updates the operation of SOC 234B. For example, if the received context information indicates that another SOC (e.g., SOC 234C) is using a frequency band to perform radio operations, SOC 234B can select another frequency band that does not interfere with other SOCs. Alternatively, if the context information indicates that another SOC uses a shared PA, SOC 234B can wait until another SOC releases the shared PA.

[0080] In one or more embodiments, the context processor 522 may also request context information from the notice board 326 when the operation of the SOC 234B changes. That is, before changing the operation of the SOC 234B, the context processor 522 requests context information from the notice board 326, receives context information from the notice board 326, and confirms whether the changed operation will cause any coexistence problems. If the change causes any coexistence problems, the context processor 522 may take actions to prevent the coexistence problems, or wait until the coexistence problems no longer exist. To this end, the context processor 522 may register at the notification circuit 480 to receive context information when coexistence no longer exists. The actions that may be taken to prevent coexistence problems may include sending commands to other subsystems, another SOC, or another system to change operations, sending requests to the coexistence hub device 212 to take actions to resolve coexistence problems, and the like.

[0081] The components and architecture of SOC 234B are merely illustrative. In other embodiments, SOC 234B may include only one communication subsystem or more than two communication subsystems. In addition, SOC 234B may include Figure 5 Other components not shown.

[0082] In one or more embodiments, SOC 234B also includes its own bulletin board 524. Bulletin board 524 can be substantially the same as bulletin board 326 in coexistence hub device 212. Bulletin board 524 can store the same context information as bulletin board 326. Alternatively, bulletin board 524 can store context information different from bulletin board 326. For example, bulletin board 524 can store context information related only to communication subsystems 536A, 536B and / or any resources outside of SOC 234B that are accessed by communication subsystems 536A, 536B. External resources can be shared by other SOCs 234 or coexistence hub device 212. The same context information stored in bulletin board 326 and bulletin board 524 can be synchronized or updated based on a voting mechanism or any other predetermined conflict resolution. Bulletin board 524 can have the same context information as described above with reference to FIG. Figure 4B The bulletin board 326 described above may have the same or similar structure.

[0083] Although the above reference Figure 5 The structure and functions of the SOC 234B are explained, but other SOCs in the system 210C or other systems 210A, 210B may have substantially the same structure and functions.

[0084] Example application processor with billboard

[0085] Figure 6 6 is a block diagram illustrating an application processor 608 and systems 630A through 630C (collectively referred to herein as “system 630”) in an electronic device according to one embodiment. Figure 6 In the embodiment of FIG. 6A , the billboard 610 is implemented in the application processor 608 rather than in the coexisting hub device 212 of the system 210C. Figure 6 The systems 630 are illustrated as being directly connected to the application processor 608, but one or more of the systems 630 can communicate indirectly with the application processor 608. In addition, a subset of the systems 630 can communicate with the application processor 608 via one type of bus (e.g., PCIe) while other systems communicate via another type of bus (e.g., SPMI). In one or more embodiments, the billboard 610 of the application processor 608 remains powered even if the power supply degrades.

[0086] The structure and function of the notice board 610 are similar to those in the above reference Figure 4BThe billboard 326 explained is substantially the same, except that the billboard 610 is contained in the application processor 608 and is not part of the coexistence control circuitry. In one or more embodiments, when context information stored in the billboard 610 is updated, the application processor 608 sends an interrupt so that the system 620 can take appropriate action. When certain context information is updated in the billboard 610, the application processor 608 can cause some components in the system 620 to wake up.

[0087] Application processor 608 may include Figure 6 Various components not shown in the figure, such as a communication interface, a processing core, and a memory for communicating with the system 630. These components are not shown in the figure. Figure 6 To avoid ambiguity of the implementation scheme.

[0088] In other embodiments, the notice board may also be in a head-end control device / subsystem that may only control a number of local radio devices.

[0089] Example Procedure for Operating a Synchronous Generator

[0090] Figure 7 is a flow chart illustrating a process of operating a notice board according to one embodiment. The notice board receives 702 context information from a first SOC (e.g., SOC 234B) via a multi-drop bus at a first time. A memory in the notice board is then updated 710 based on the received context information of the first SOC.

[0091] The coexistence hub device detects 714 an event in a second SOC (e.g., SOC 234C). Such detection may be made by a message received via the multidrop bus indicating, for example, that the second SOC has become active from a sleep mode, or by a message including a request for context information from the second SOC.

[0092] In response, the context information of the first SOC is retrieved by the notice board at a second time after the first time and sent 718 to the second SOC. Based on the context information, the second SOC can control or adjust its operation or the operation of other SOCs. Alternatively, the second SOC can also receive a notification from the first SOC that the first SOC has updated its context information in the notice board. For example, if the context information received at the second SOC indicates that the operation of the first SOC as indicated by the context information may cause a conflict (e.g., interference of the communication frequency), the second SOC may issue a command to the first SOC to adjust the operation of the first SOC or adjust its own operation to avoid the conflict. As another example, the second SOC may request the first SOC to release control of the shared resource. In response, when the shared resource is to be released and can be used for the second SOC, the first SOC sends a reply to the second SOC. When the first SOC continues to use the shared resource response, the coexistence hub device 212 may intervene and coordinate the use of the shared resource between the first SOC and the second SOC.

[0093] Despite Figure 7 Not shown, but an additional process of determining whether the first SOC or the second SOC has the authority to update or send the context information may be performed before updating 710 the memory or sending 718 the context information. Also, upon detecting an update in the context information, an additional process of sending the context information or notification may be performed by the notice board.

[0094] While specific embodiments and applications have been illustrated and described, it should be understood that the invention is not limited to the precise construction and components disclosed herein, and that various modifications, changes 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 the present disclosure.

Claims

1. An integrated circuit, comprising: a processor configured to store an operating policy for controlling operation of the integrated circuit, wherein the operating policy is received from an application processor; one or more communication subsystems; as well as a control circuit coupled to the processor and the one or more communication subsystems and configured to be programmed by the processor to execute the operation policy by making decisions on coexistence events defined by the operation policy that prompt coordination of operation of the integrated circuit, publish messages to the one or more communication subsystems, or send messages to one or more system circuits coupled to the integrated circuit.

2. The integrated circuit of claim 1 , wherein the processor is further configured to send a portion of the operating strategy to a system circuit in one or more system circuits coupled to the processor via a multi-drop bus to program the system circuit to operate based on the portion of the operating strategy.

3. The integrated circuit of claim 1, wherein the processor is configured to make one or more decisions based on the operating policy by analyzing messages received from the one or more system circuits or the one or more communication subsystems.

4. The integrated circuit of claim 1 , wherein the processor is configured to store status information of the one or more communication subsystems, wherein the status information comprises a radio frequency (RF) band or channel used by the one or more system circuits or the one or more communication subsystems.

5. The integrated circuit of claim 1 , wherein the control circuit comprises: a scheduler configured to filter and send messages including context information of the one or more communication subsystems; as well as A billboard circuit is configured to store context information received from the one or more communication subsystems or the one or more system circuits.

6. The integrated circuit of claim 5, wherein the context information is received from the one or more system circuits via a multi-drop bus and by the scheduler, the scheduler being configured to send the context information to the billboard circuit. 7 . The integrated circuit of claim 5 , wherein the context information triggers one or more operations performed by the one or more system circuits configured to receive the context information.

8. An integrated circuit according to claim 5, wherein the bulletin board circuit is further configured to store a group of data packets sent from a source system circuit selected from the one or more system circuits and transmitted to the integrated circuit via a multi-drop bus, and wherein the group of data packets are available to system circuits in the one or more system circuits that are in a sleep state and are unable to receive the group of data packets when the group of data packets are transmitted by the source system circuit.

9. The integrated circuit of claim 5, further comprising: An arbiter circuit is coupled to the scheduler and the billboard circuit and is configured to coordinate operations of the one or more communication subsystems or resolve competing demands for common resources requested by the one or more communication subsystems.

10. The integrated circuit of claim 1, further comprising: A multi-drop bus couples the control circuit with the one or more system circuits.

11. A notice board circuit, comprising: a memory circuit configured to store context information received from one or more system circuits via a multi-drop bus and indicative of an operational state of the one or more system circuits; as well as ； a security check circuit coupled to the memory circuit and configured to: determining whether a request received from a system circuit configured to write the context information or read the context information stored in the memory circuit is authorized to access the memory circuit by the system circuit; and The request is granted in response to determining that the system circuitry is authorized to access the memory circuitry.

12. A notice board circuit according to claim 11, wherein the context information includes a device address data field or a security code data field, the device address data field indicates a physical or logical address of the system circuit associated with the context information, and the security code includes data for authenticating whether a request by the system circuit to read or write the context information is authorized to access the memory circuit.

13. The billboard circuit of claim 11 , wherein to determine whether the request received from the system circuit is authorized to access the memory circuit, the security check circuit is configured to: determining whether a device address or a security code included in the request from the system circuit matches a corresponding device address or a corresponding security code stored in the memory device; and In response to determining that the device address or the security code included in the request matches the corresponding device address or the corresponding security code, enabling memory access circuitry of the billboard circuitry to read context information from or write context information to the memory circuitry.

14. The notice board circuit according to claim 11, further comprising: A status checking circuit is configured to receive periodic heartbeat messages from the one or more system circuits and perform an operation of updating or locking the context information of the one or more system circuits stored in the storage circuit.

15. The notice board circuit according to claim 11, further comprising: Notification circuitry is configured to track updates to the context information stored in the memory circuitry and send notifications to the one or more system circuits.

16. A method comprising: storing, by a processor, an operating policy for controlling operation of an integrated circuit, the operating policy being received from an application processor, and the integrated circuit comprising the processor, control circuitry coupled to the processor, and one or more communication subsystems; as well as The control circuit is programmed by the processor to execute the operating policy by making decisions on coexistence events defined by the operating policy that prompt coordination of operation of the integrated circuit, publish messages to the one or more communication subsystems, or send messages to one or more system circuits coupled to the integrated circuit.

17. The method according to claim 16, further comprising: A portion of the operating strategy is sent via a multi-drop bus to a system circuit of the one or more system circuits coupled to the processor to program the system circuit to operate based on the portion of the operating strategy.

18. The method according to claim 16, further comprising: Messages received from the one or more system circuits or the one or more communication subsystems are analyzed to make one or more decisions based on the operating policy.

19. The method according to claim 16, further comprising: State information of the one or more communication subsystems is stored by the processor, wherein the state information includes a radio frequency (RF) band or channel used by the one or more system circuits or the one or more communication subsystems.

20. The method of claim 16, further comprising: Context information received from the one or more communication subsystems or the one or more system circuits is stored by a billboard circuit of the control circuit, wherein the context information triggers one or more operations performed by the one or more system circuits that received the context information.

Images