The wireless industry is adopting platform-based design methodology on a wide scale in digital baseband and application chips. These platforms typically consist of processors and other IP-blocks that come from a few vendors, with wireless and other value-add logic designed in-house. An end-product manufacturer or a component vendor integrates the platform, depending on the business model. Integrating IP from different sources proves to be difficult especially from system-level design perspective, since for example RISC and DSP processors have different preferences for interfaces and interconnects.
Wireless System-on-Chips (SoC) are often designed around processor cores, with the processor being the main driver for the architecture. The chip interconnect features are effectively driven by the processor vendor's preferences. In practice, this means gluing together two different processor and bus systems, since 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, with HW-SW partitioning options limited by the interconnect architecture. Previous processor cores came with a RAM interface optimized for code execution, and perhaps a peripheral interface capable of control rather than massive data pumping. This has been quite adequate for low bit-rate and voice-only platforms.
Third generation wireless (WCDMA, CDMA2000) comes with higher bit-rates, reaching several megabits per second. The raw data can ping-pong between modem processing elements with even higher-level bit-rates. The high data-rate systems are also packet rather than circuit switched. Therefore, it makes sense to design the platforms communication centric instead of processing centric.
A communication-centric platform means an architectural reference for interconnect, providing adequate data and control transfer capacity between processing elements. The interconnect structure can be a traditional bus or an on-chip network. Since the system is built around the interconnect platform, heavier investment can be made to the communication modules making them more capable. The interconnect platform can even have active control elements for traffic and energy control. Processors are selected and connected to this architecture as any processing elements according to the required capabilities. But if the processor interfaces remain proprietary and quirky, requiring heavy-handed wrapping to the communication architecture this does not lead to much better solutions than the processor centric platforms.
Enter standardized, open interfaces: A good interface standard supports high-performance features such as pipelining and threads, and is feature rich to make proprietary interfaces obsolete. The standard must define protocols clearly and unambiguously, and allow automated verification for compliance. Openness of the standard is important in ascertaining wide support with features that take consideration not only IP vendors' or system integrators' requirements, but satisfies all users. The users can affect the contents of an open standard, and do not need to rely on a single vendor or industry cliques 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 design methodology. This is somewhat misguided criticism, since SoC design is never about connecting Lego-like blocks, but rather about system analysis and building a design that fulfills specified functional and performance requirements. Connecting any two OCP blocks together rarely happens wire-by-wire since there are dozens of possible interface configurations. What the standard gives the user is a well-defined way to parameterize and build an interface with wanted features. For example, a pipelined interface cannot be connected to a non-pipelined interface without performance loss, but when both interfaces conform to a standard this connection can be done with minimum losses.
As mentioned above, wireless SoC design is about system analysis. Therefore, interoperable interfaces alone do not guarantee a working system. They do help in developing modeling methods with interface performance built-in. A good example of this is the development of SystemC transaction libraries by the Open SystemC Initiative and the OCP-IP organization. Using a standard interface as a basis for transactional modeling lifts the platform performance analysis above RTL, with little loss in simulation accuracy, but large gains in speed.
With open interface standards, IP vendors and system integrators get a common lexicon for expressing functional, timing and performance features, and can assume maximum interoperability for their modules within defined parameters. Processor core vendors can concentrate maintaining the superiority of their technology rather than trying to hold on to their customers with proprietary interfaces. All IP vendors lower support cost for not needing to support a variety of bus interfaces. System integrators can select the most suitable IP blocks according to their product requirements, and analyze and create product variants more easily. In short, open standards are good for the industry as a whole.
Please share your thoughts about this feature article with our readers by contacting the editor at: firstname.lastname@example.org