It's a common request made of many systems designers: create a set of designs with the same basic functionality, but each version of the design must offer a different feature set. The intuitive approach to this problem creates and verifies a base design, then creates the remaining design elements needed to provide the necessary additional functionality. It's a practice referred to as platform-based design.

Recently, with device sizes moving into the multimillion gate range with intense demands placed upon design engineers to rapidly create and verify systems, design teams are beginning to pursue development approaches that will easily integrate intellectual property (IP)—both internally and externally generated. Current estimates place the average amount of design reuse in new system-on-a-chip (SOC) design at somewhere around 40 percent, a number that has been steadily rising and will likely continue to rise as device densities outstrip the designer's ability to fill them from scratch. Increased IP use encourages platform-based design by allowing designers to focus on their core competencies while other designers fill in the gaps in the other areas. Designers today encounter, unfortunately, significant barriers to increased IP use, generally in the areas of identification, integration, and verification.

Locating the right IP from outside sources can be quite difficult. Equally challenging, internally generated IP often goes unidentified and under-utilized if the company has no infrastructure for distributing to designers in-house. To address some of these problems, many silicon vendors are partnering with IP providers or developing IP themselves. These partnerships work toward many goals, ranging from simply raising awareness of available IP to producing architecture-optimized versions of IP products and associated test benches for facilitating integration and verification.

Programmable logic vendors have many incentives for making strong partnerships with—or becoming—IP vendors. PLDs provide good vehicles for verifying IP-based designs since their development times are relatively short and allow designers to test quickly the hardware implementation of a design composed of IP elements from multiple sources. Further, IP intended for PLDs must generally be more optimized for the target architecture than ASIC-targeted IP, and PLD vendors have an interest in ensuring that IP providers understand that. Finally, while a single programmable device or set of devices might be used to develop and verify a base design, the same or similar set of hardware components can be used later in the development of additional feature sets, resulting in substantial cost savings in test and manufacturing.

Platform-based design involving IP and programmable logic promises other benefits as well. If the IP integration process is sufficiently streamlined, the development of new products might demand far less development time, requiring only that the new IP be integrated and verified. Changing or evolving standards might force a design modification that could be more easily accommodated with the inclusion or exclusion of IP. The rapidity with which PLD-based designs are implemented means that proof-of-concept and demonstration systems can be quickly realized. Also, programmable logic can be used throughout the manufacturing phase as appropriate, particularly in early manufacturing to meet initial market demand while finalizing feature sets, or during production if market demand doesn't warrant the cost associated with migrating a design to an ASIC.

IP accelerates design cycles

The conditional-access emulator designed by General Instruments (now Motorola's Broadband Communications Sector) for set-top boxes illustrates the advantages of a platform-based design approach. The explosive growth in the set-top box and other broadband transmission product markets, as well as the rising demand for the services such products offer, has created an environment of changing standards within the industry. One of the critical steps in the development of these devices is the creation of conditional-access system firmware, which controls the descrambling and decryption of incoming data.

In order to streamline and shorten the development cycle for all of its broadband products, General Instruments decided to create a single platform design for a conditional-access emulator that could be used by its various groups for the development of firmware forany given product. Such a platform design would have to be flexible enough to meet the needs of the various products in development, and it would have to be modifiable to accommodate the next-generation products. Additionally, as with many projects, cost reductions and a shorter design cycle were also desired.

General Instruments possesses a strong portfolio of decryption-related IP that would be instrumental in the design, but some elements, including a PCI interface and a 32-bit processor, would have to be developed internally or obtained externally. Previously, the design team would approach this type of project by implementing the design using an ASIC emulator and then converting the design to an ASIC. For this project, however, encouraged by the increasing size of PLDs, the growing amount of PLD-optimized IP, and the rapidity with which programmable logic could produce a functioning product, the design team investigated a programmable logic implementation. They identified specific PLDs that would result in a lower-cost implementation, but more importantly, they determined that the PLD vendor's IP partners offered several cores that would meet their needs.

The first emulator that the General Instruments engineers would design with this approach was called the MC2. It included several functional modules, including conditional access, decryption, I/O interfaces, and processors for both conditional access and out-of-band processing. The only MC2 emulator elementsthat wouldn't fit the PLDs were the memories for the processor instruction sets, configuration information, and buffer space for out-of-band processing; the size of these was larger than any programmable device could provide. As a result, these were held in external FLASH and RAM (see Figure).

Figure 1 - Modules in MC2 emulator

The shared functionality of three General Instruments conditional-access systems: MC2 emulator (blue & red), point-of-deployment emulator (red & green), and next-generation MC2 emulator (all colors).

The challenge of realizing the MC2 emulator design was in integrating several large, complex blocks of IP, some externally generated (the PCI interface and processor cores, each from different companies), and some internally generated (for instance, the decryption blocks, HASH engine, MPEG transport parser). Understandably, the most difficult IP to integrate is often the one that is created external to the company. At a minimum, thorough documentation and some degree of support is required for such IP and, often, test benches or vectors are also necessary to aid the verification process. Questions about the IP vendor's knowledge of the hardware implementation and long-term support, as well as any customization requirements, need to be fully explored and answered before a design team can proceed with using external IP.

When IP from multiple sources must interact in the same design, verification must be especially rigorous and specific if any difficulties arise and support is required from one or more of the IP providers. In the case of the MC2 emulator, the General Instruments design team selected cores from PLD vendor partners and thus was assured that they would get IPthat was optimized for the target PLD architecture. More importantly, for the complex integration and customization of the 32-bit processor cores, they got cooperative design support from both the IP vendor and the PLD vendor, who had previously worked together totarget the processor to the PLD architecture of GeneralInstruments' choice.

The design occupied six EPF10K200E devices, totaling over one million gates (each of the EPF10K200E devices provides roughly 200K gates). The initial cost savings in this approach are indicated in the difference in the hardware costs; a million-gate ASIC emulation system can cost in the hundreds of thousands of dollars for a single design seat, whereas the cost of a couple EPF10K200Es (at the time) was in the thousands of dollars. The working design was completed and in the hands of firmware developers in two months, which was a fraction of the amount time it would take to realize a working system with an ASIC. Further, while the ASIC emulation system was limited to typically 1 MHz operating speed, the PLD-based implementation ran in the tens of MHz range.

Internal IP and design reuse

Most IP that is used in designs is internally sourced—it's generated within the designer's company. Although many companies use internally generated IP, few have an infrastructure in place that formalizes its availability and distribution. For many companies, a lack of such an infrastructure can be a significant barrier to reaping the benefits of design reuse.

The next generation of General Instruments' conditional-access emulators encompasses functionality included in both the original MC2 and the POD card(see Figure 1). As a result of their having proven out much of the IP integration and verification tasks in the previous products, these design teams that practiced platform-based design expect their development cycle to be shorter and more streamlined.

Maximizing the benefits of platform-based design demands that IP opportunities be taken whenever possible. For internally generated IP, this means creating an infrastructure or at least an environment of IP awareness and distribution. For external IP, it means identifying reliable sources that are knowledgeable enough about your hardware implementation to provide real aid in both integration and verification. In implementation, it means utilizing hardware components that can quickly produce working models for ease of verification and short time-to-market. If enacted and followed, platform-based design practices deliver a streamlined route to finished product, flexibility in the face of changing or evolving standards, and shorter development times for both variations on products and their successors.