This invention relates generally to multiprocessor mobile devices.
Mobile devices such as cellular telephones and personal digital assistants may have highly evolved processing capabilities. In some cases, separate baseband and application processors are provided. The baseband processor may provide communication capabilities while the application processor may handle a range of other tasks such as providing user interfaces, multimedia application handling, operating systems, and communicating with peripherals. The baseband processor may include radio frequency controls, communication protocols, and provide data and voice processing.
Conventionally, the baseband and application processors communicate over an appropriate interface, such as a peripheral bus or serial interface. Voice processing is normally handled in a chipset coupled to the application processor. As a result, the application processor may be bogged down with elaborate voice processing.
One application for multiprocessor systems of this type is called the Voice Over Internet Protocol (VOIP). VOIP is the transport of voice packets over Internet protocol network. Such systems may use a network processor to implement various communication protocols.
The conversion of analog voice data into digital packets may be handled by an encoder/decoder or codec. However, the interface between the codec and the application processor may have a number of undesirable consequences. During Internet Protocol communications for a VOIP application, there may be little need for the application processor to remain in a powered-up state. Thus, the only activity on the application processor may be sending data to the codec. As a result, the application processor must remain powered up to handle the auxiliary codec hardware.
It would be desirable to reduce the power consumption of mobile or battery powered devices. Because they have limited power supplies, it would be desirable to provide alternate ways of implementing mobile multiprocessor systems that reduces their power consumption.
Referring to
The processors 12 and 18 may communicate through a peripheral bus 16. The peripheral bus 16 may be a conventional bus, or in other embodiments, it may be a physical interface such as a serial link. The processor 12 may communicate with the auxiliary device 20 through another serial interface. The AC '97 link is one example. See Audio Codec '97 Component Specification, v. 2.3, release 1.0, July 2002, available from Intel Corporation, Santa Clara, Calif.
The auxiliary hardware device 20 may have two ports, or use a shared port, so that it may be accessed by both processors 12 and 18. However, instead of requiring the application processor 12 to always interface with the device 20, the baseband processor 18 may also communicate with the device 20 as indicated by the arrow A. This may enable switching of the handling of the device 20 between the processors 12 and 18.
For example, in voice over Internet Protocol (VOIP), conversion of analog voice data to digital packets in a codec may involve a number of machine instruction cycles. In one example, the device 20 may be a codec. As a result, the application processor 12 may be unable to power down to save power, even in those cases where the only function being implemented by the processor 12 is supporting the hardware device 20. The other communication protocols (other than the encoder/decoder function) may be handled by the baseband processor 18. In such case, the application processor 12 would have to remain powered up simply to handle the device 20, which the baseband processor 18 could readily handle itself. If the baseband processor 18 is handling the VOIP operation it would be unable to power down anyway. However, but for the need to handle the codec, the application processor 12 could power down to a lower power consumption state in this example.
Thus, as shown in
In one embodiment, the baseband processor 18 may be a wireless baseband processor. One such wireless baseband processor may be an 802.11 standard processor. See IEEE Std. 802.11-1997, available from IEEE, Inc., New York, N.Y.
The baseband processor 18 may itself access the hardware device 20 which in this example may be a codec. Then data transfer over the network may flow directly between the baseband processor 18 and the hardware device 20 with no involvement required from the application processor 12. A power savings may result in some embodiments because the application processor 12 can power down to a lower power consumption mode. In addition, system traffic may be reduced in some embodiments, which may also reduce power consumption.
Conventionally, packet processing is done by the application processor 12 that reads from the device 20, processes the packets, and then writes them to the memory 14. The device 20 is conventionally a separate device that is shared with the application processor 12. The ability for each processor to access the device 20 may result in significant power savings since the application processor 12 may assume a lower power consumption mode when unneeded to interface with the device 20 and when it has no other active tasks. Additional power savings result from the reduction in multiple data transfers.
Thus, inbound data packets may be transferred from the baseband processor 18 to the memory 14. The processor 18 then reads the data from the memory 14 and performs a decode function. That data is then transferred to the device 20. Similarly, the outbound data is read from the device 20, processed by the processor 18, and then written to the memory 14. Then the data is transferred to the baseband processor 18 to be sent over the network. During this sequence of events, the application processor 12 may be powered down.
By enabling the encoder/decoder processing to be handled through the baseband processor 18, the application processor 12 may be idled, resulting in power consumption savings. That is, the baseband processor 18 may read the data from memory and perform the decode function. Then the data may be transferred to the device 20. Outbound data may be read from the device 20, processed by the baseband processor 18, and then written to a memory associated with the baseband processor 18. That data is then transferred to the baseband processor 18 to be sent out over the network interface 22.
The device 20 may be a subscriber line interface circuit, encoder/decoder in one embodiment of the present invention. Application layer software may handle voice and telephony digital signal processing tasks, such as echo cancellation, compression/decompression, and tone detection in some embodiments.
The memory 14 may be a semiconductor volatile or non-volatile memory in some embodiments. As examples, it may be flash memory, ovonic or phase change memory, polymer memory, electrically eraseable programmable read only memory, static random access memory, or a synchronous dynamic random access memory.
In some embodiments, the device 20 may be a separate device. In other embodiments it may be integrated into one of the processors 12 and 18 or some other component.
Examples of the device 20 may include image data processors, such as graphics accelerators, display controllers, and cameras. The device 20 may also be an encryption/decryption engine as still another example.
As another application in which the device 20 is a codec, a cellular network may be implemented. In such case, the codec may handle streaming audio data.
The application processor 12 and the baseband processor 18 may each store the software 24 to implement hardware sharing. The hardware share software 24, shown in
If so, in one embodiment a check at diamond 30 determines whether the other processor is powered up. The other processor, in the case of software running on the baseband processor 18, would be the application processor 12 in the illustrated embodiment and vice versa. If the other processor is not powered up, then the processor running the software 24 directly accesses the auxiliary hardware device 20 itself as indicated in block 32. However, if the other processor is powered up, at least in some cases, the processor running the hardware share software 24 may access the auxiliary hardware device 20 through the other processor as indicated in block 34. However, it may be advantageous for the processor executing the software 24 to handle the device 20 itself, even if the other processor is powered up.
While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.