| Early attempts to make large, configurable intellectual property blocks reusable in a plug-and-play fashion have achieved mediocre success at best. Engineers experience many headaches getting complex and configurable IP subsystems like USB 2.0 and Bluetooth working within their existing architecture. Many of the difficulties can be overcome, however, with the use of a more holistic approach. Using Bluetooth IP as an example, some of the design challenges include: Nonstandard interfaces. System designers are finding it more cost-effective to use a small external radio chip, rather than bring RF on-chip and be forced to deal with the complex issues of integrating a mixed-signal RF block. The Bluetooth radio interface is not standardized, and baseband controllers must support several RF devices for commercial success. IP requiring modification has less value to the integrator than preverified IP. Firmware with real-time requirements. It's far easier to implement much of the functionality in embedded software — as long as this firmware can serve real-time requirements. If this code is sharing the SoC's main processor with the application software, it becomes the integrator's responsibility to merge the code, and it is difficult for the IP provider to guarantee the necessary real-time responses. Sharing the processor turns this into a custom development, not IP reuse. Gate count and memory bloat. Bluetooth hardware and software benefit greatly from being configurable. Area and memory footprint can be reduced up to 40 percent by stripping away unnecessary logic and functions. The challenge is in finding an IP architecture that provides for this configurability without introducing the need for customization Plan configurability up front. This would include configuration not only of the RTL but also of the associated firm- ware, drivers and tests. For our recently launched XBlue 1200 Bluetooth core, we carefully planned what should be configured in the hardware that would be realized in the final silicon and what would be configured in software that could be changed at the board level and over the course of the chip's life. Partition the architecture along standard interface boundaries, Proprietary interfaces should be avoided wherever possible to maximize reusability. Partition the implementation to minimize technology-specific sections. Either avoid them altogether or isolate them from the fully reusable sections of the IP. Provide integration tests that follow the IP configuration. It is much easier for the integrator if the testbench automatically tests only for the configured functions and just gives a simple pass/fail result, as ours does. This requires that the integration tests be based on the configuration settings. Stefan Schmechtig (stefan.schmechtig@ip-extreme.com) is program manager for IPextreme Inc. (Campbell, Calif.).  See related chart | 
