In the domain of deciding which embedded functionality should go in hardware and which in software, some architects have a philosophy of keeping as much in software as possible. That’s because software is inherently much more flexible than hardware. Even if you’re using an FPGA, there’s always the, “what if it doesn’t route?” fear. With software, as long as it fits in the allocated code store, you can do anything you want.
This is, of course, part of the motivation of software-define radio (SDR). Years ago, I would hear SDR articulated as a godsend to the military so that they could manage their complex communications more readily.
Now it’s starting to look viable for cell phones. Icera, acquired by Nvidia, is there, and CEVA has just made a couple of SDR-related announcements.
The first relates to GPS: rather than adding hardware to implement GPS, CEVA partner CellGuide proposes to implement a software version, which requires no new hardware. The GPS function would run as a lower-priority function in the background, ceding to calls and browsing and other higher-priority tasks.
Then CEVA announced library support for HSPA+ (“Evolved High Speed Packet Access”… these acronyms never seem to contemplate the fact that there will be more after them… “evolved” and “long-term” and the like will seem so quaint ten years from now…). The idea is to further enable a software implementation of a multimode HSPA/HSPA+/LTE/LTE-A platform. (See? How long-term was it before they had to append a “-A”?)
A big motivation for doing all of this in software is that, traditionally, each call mode can require its own hardware, so you end up with more chips and higher power and higher cost. If instead you just have a processing platform (which, clearly, CEVA would like to include their DSP engine, for which their libraries are obviously optimized), then you just pull up and execute the code for whichever protocol is being used at the moment.