Bluetooth Basesband IP in an ARM9 Environment

Bluetooth Basesband IP in an ARM9 Environment
by Jeff Robertson, Ericsson Technology Licensing
Daniel Nilsson, Ericsson Technology Licensing
Lund, Sweden

Abstract :
Bluetooth is a commodity and commodities are driven by cost. But, the key to driving down cost is integration and sharing of common resources. With Baseband functionality, the key to integration is to have an understanding of the CPU demands from both a systems perspective as well as a focused Baseband function perspective. Finally, the key in understanding the CPU demands of the system for integration is knowing the integration models and associated issues for consideration. For example, what are the existing resources that can be shared, such as Uarts? Are there any system latency restrictions that already exist? What are the memory requirements? And of course, how important is Bluetooth functionality to the system? One major way to put the integration models in perspective is by knowing the major segments and their driving factors.

Bluetooth Basesband in an ARM9 Environment
The ARM7 is definitely the most common CPU used in the Bluetooth market today. It has been chosen as a good basis of familiarity and has been well known in the Mobile Phone segment for years. It is a powerful CPU, just in case need arises. The ARM7 certainly has a stable environment with solid development platforms, a wide proven track record of successful products, and the famous AMBA backplane. But, Bluetooth Baseband structures are now mature enough to re-evaluate CPU selections. The ARM7 CPU was a good start for Bluetooth Basebands, but is probably no longer the selection of choice for next generation Bluetooth Baseband development.

So, why is that? The ARM7 certainly has a lot of pluses. It is the most common CPU core used today. It has good low power consumption. Probably every peripheral on the digital market is laid-out and tested to work with ARM7 cores. But, it is too powerful for simple applications and not quite powerful enough for the ever increasingly complex applications. And ARM7 is certainly a very expensive solution for using in dedicated Bluetooth chipsets.

It is time to evaluate the CPU migration for Bluetooth Basebands. In fact, it is quite easy to reach the conclusion to migrate, but where should Bluetooth Basebands migrate? What is CPU of choice for the coming generations of Bluetooth Basebands? What integration models and CPU demands are being made from each respective segment? Our first approach to this problem has been to gather as much relevant information as possible to help guide us as we plot our course for migration. We interviewed the major OEM players in Mobile Phones, PDA's, Digital Cameras, and numerous others to hear their thoughts and opinions on the future of their products. We paid attention to relevant news flashes and press releases that might show us indications in CPU trends. Such as articles announcing that Palm and Handspring have decided to drop their long-standing tradition of Dragonball CPU's to use Arm CPU's instead. Press Releases from Motorola stating that they would redesign the Dragonball processor to run on an ARM core were taken into account. Industry articles discussing the mobile phone dilemmas of trying to solve ‘open platform' issues without opening access to, or de-prioritizing the 3G processing requirements have been closely followed. Finally, we held numerous in-depth discussions with Arm, the owner of the lion's share of the CPU core market, to make sure we clearly understood the world according to Arm.

So what has our approach to this problem resulted besides the obvious conclusion that we would like to know much, much more? Well, we have been able to identify some of the major trends and issues in different segments. We have been able to surmise a series of CPU strategies based upon system requirements. These CPU requirements strategies are based upon: application variations, multi-tasking CPU core needs, the integration or division philosophies of system functionality, the trade-off issue of Cache versus Latency, and of course the ever present issue of interrupts. Finally, we have mapped these CPU strategies by segment group to identify each segment's roadmap of CPU's and integration models to best fit each segment's unique CPU issues and requirements.

Mobile Phones Segment –
Mobile phones going into the 3G future have a lot of system architecture issues that play direct roles in identifying the future of CPU cores. The big question is how to develop a half-open platform to allow downloadable content without disturbing the important real-time operation requirements to keeps the phones connected to the networks? Basically, the mobile phone platforms are feeling the strain against the current highly integrated hardware and software systems because it is getting too difficult with the ever-increasing software loads. This is also compounded by the closely coupled massive increase in memory demand and thusly, the memory management needs. The architecture of choice for 3G phones will most likely be a division of real-time and non-real-time systems. In this architecture, we will probably see the continuation of the ARM7 CPU core running the real-time Baseband that controls all radio functions, while an ARM92x core will be used to control the non-real-time critical processing. For mobile phones targeted towards the classical non-web users, or conversation concentrated users, a continuation of high hardware and software integration would warrant the use of an ARM96x to control the entire system.

PDA's Segment –
PDA's are always increasing functionality and this is primarily done in software. The historical demands for processing in the system are not very real-time critical, especially compared to radio intensive segments such as mobile phones. PDA's strongly embrace a platform openness that cultivates a plethora of downloadable content for PDA's and demands good memory management. This also implies a delicate balancing act to keep cost, size and power from increasing symmetrically with functionality. PDA's are also looking to get a piece of the high volume mobile phone pie by trying to integrate telephony functionality. Based upon these facts, the PDA segment requires the use of an ARM92x core with the possible addition of an ARM7 sub-system to control the real-time requirements.

Digital Camera Segment –
Although digital cameras certainly do not demand the same level of real-time critical response as a mobile phone system, there is a kind of "real-time" total system processing need. The difference is that the system is much more focused towards the tasks of capturing and storing images. Digital camera platforms are closed platforms that warrant a very close hardware and software integration level. Unfortunately the industry is still relatively new and, thus, there is a need to fit to differing system strategies. Memory is not used for a variety of different tasks, so no memory management function is needed. An ARM94x can control the entire system, including the Bluetooth functionality required.

Headset Segment –
Headsets do not do very much more than eliminate the cable to the mobile phone and the unique connector that eliminated the possibility of ever having a universal headset working with all mobile phone brands. The current solutions based upon the ARM7 cores are definitely an overkill of functionality. Secondly, if headsets are universal, the only differentiating factors for headsets are price and looks. Neither of which warrants the need to use an ARM7 CPU. In fact, is there really a need for a CPU processor at all? As this system is extremely closed, doesn't require very much processing power, and could certainly benefit from the tightest hardware and software integration possible to bring down the costs, it may be more feasible to consider embedding enough processing power in the Bluetooth Baseband to control the entire system and eliminate the need for a CPU completely.

HID Segment (Mouse and Keyboard) –
The same basic arguments and conclusions as the headset segment can be used for the HID segment. Actually, the elimination of voice functionality further simplifies the processor requirements as no noise reduction or echo cancellation is needed. The need for data processing is basically limited to buffer handling and Bluetooth control functions. Perhaps the HID segment only makes the ARM7 even more of an extreme over-kill compared against the system requirements and considering the desire to maximize battery life.

In conclusion, we can see that there is a clear division of two sides for the migration of CPU cores used in Bluetooth Basebands. The highly complex platforms, such as mobile phones, PDA's, and Digital Cameras are increasing in complexity and increasing in processing demands. While the basic platforms, such as headsets and HID devices cannot justify the costs of continuing with the ARM7 environment, or perhaps any CPU core at all.

The actual migration to an ARM9 environment is the easy part. Since we started with a Baseband solution intended for integration in an overloaded ARM7 environment and using the AMBA backplane, we are able to leverage all the benefits of experience and design structure from our ARM7 work. The trends in increasing demands of more important functions in the ARM9 (and even the future ARM7) platforms only reiterate the fact that Bluetooth is a commodity function in a system that allows the Bluetooth Baseband to demand the CPU priority of a very minor portion of the total system requirements.