wireless system design

The wireless industry is eagerly adopting platform-based design methodologies for digital baseband and application chips. Typically, such platforms consist of vendor-provided processor and IP blocks. Wireless and other value-added logic is designed in house. Depending on the business model, an end-product manufacturer or component vendor integrates the platform. Integrating IP from different sources can prove to be difficult—especially from a system-level-design perspective. Usually, this difficulty is spawned by processor-interface and interconnect differences (e.g., between RISC and DSP cores).
Often, wireless systems-on-a-chip (SoCs) are designed around processor cores. Those cores are the main drivers of the chip’s architecture. The chip-interconnect features are effectively driven by the processor vendor’s preferences. In practice, this means that two different processor and bus systems have to be glued together. After all, baseband chips execute both control-type and DSP-type tasks. Adding air-interface-specific logic (like a RAKE receiver) to the processor platform comes almost as an afterthought. And hardware-software partitioning options are limited by the interconnect architecture.
Previous processor cores came with a RAM interface that was optimized for code execution. Perhaps they also had a peripheral interface, which was capable of control rather than massive data pumping. This approach has been quite adequate for low-bit-rate and voice-only platforms.
The challenge comes with high-bit-rate, third-generation (3G) wireless networks like W-CDMA and cdma2000. The raw network data ping-pongs between modem-processing elements, which have rates that are tens of times higher than the incoming network traffic. In addition to high data rates, 3G networks are packet rather than circuit switched. It therefore makes sense to design communication-centric rather than processing-centric platforms.
A communication-centric platform is built around interconnections. Those interconnections maintain adequate data and control transfer capacity between processing elements. The interconnect can be a traditional bus or an on-chip network. Because the system is built around the interconnect platform, heavier investments can be made to expand the capabilities of the communication modules.
As with any other processing elements, processors are selected and connected to this architecture. If their interfaces remain proprietary and quirky, much heavy-handed wrapping to the communication architecture is required. Little is gained over traditional processor-centric platforms.
Here, standardized open interfaces can make a difference. A good interface standard supports high-performance features like pipelining and threads. It also is feature rich, which helps to make proprietary interfaces obsolete. To achieve this goal, the standard must clearly define all protocols. It has to allow automated verification for compliance.
The openness of the standard also is important. Openness encourages wide support from IP vendors, system integrators, and all other users. Those users can affect the contents of an open standard. Plus, they don’t need to rely on a single vendor or industry clique for support and future development.
Socket interfaces, such as OCP and VSIA’s VCI, have been criticized for not creating true plug-and-play SoC designs. This criticism is somewhat misguided. SoC design is never about connecting Lego-type blocks. Instead, it’s about system analysis. It also is about meeting functional and performance requirements. Connecting any two OCP blocks together rarely happens wire by wire. After all, there are dozens of possible interface configurations. The standard gives the user a well-defined way to parameterize and build an interface with wanted features.
As mentioned, wireless SoC design is about system analysis. Interoperable interfaces alone don’t guarantee a working system. Yet they do help to create modeling methods with built-in interface performance. For an example, look at the development of SystemC transaction libraries by the Open SystemC Initiative and the OCP-IP organization. By using a standard interface as a basis for transactional modeling, the groups lifted the platform performance analysis above RTL. They suffered little loss in simulation accuracy while enjoying large gains in speed.
With open interface standards, IP vendors and system integrators can share a common lexicon for expressing functional, timing, and performance features. They also gain maximum interoperability for their modules within defined parameters. Processor-core vendors can compete on technology superiority instead of holding onto their customers with proprietary interfaces. IP vendors lower support costs by reducing the number of supported bus interfaces. System integrators can select the most suitable IP blocks according to their product requirements. Those integrators also can analyze and create product variants more easily. In short, open standards are good for the industry as a whole.