|
|
|
|
|
|
 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Using a Versatile, Independent IP Platform for SoC Design
By Jim Bruister, SoC Solutions, Inc.
Bill Finch, CAST, Inc. Introduction Recent years have seen the practice of reusing IP cores or buying third-party IP evolve from an option to a necessity. The “make versus buy” decision has strongly shifted to the “buy” side, and designers hope to purchase “expertise” and “reduced risk” as much as “shorter time to market.” Today most new product designs include at least one embedded microprocessor or microcontroller. Developing the ASIC or ASSP chip — or, increasingly, the FPGA — that contains the processor and related functions can be the most critical part of the project. Processor-based SoCs have their own set of design and verification issues, and require a varied set of hardware, software, and architecture expertise. This has led to the application of the reusable IP approach to complete systems or subsystems, and the emergence of “platforms” as new IP products. This paper shows how companies adopting an IP platform approach can maximize the benefits of their investment by choosing a flexible, versatile platform suitable for a variety of projects. Major points to consider are illustrated through one such platform, the PIP-AMBA from CAST. IP Platforms are SOC Infrastructure Subsystems The term “platform” is greatly overused in the electronics and semiconductor industry. In the context of this paper, we define IP platforms to be “SOC infrastructure subsystems,” or, more specifically, “embedded microprocessor-based SOC subsystems.” A platform or subsystem combines multiple IP cores, providing a variety of necessary functions useful for a multiple processor-based SOCs. This typically includes input/output interfaces, communication operations, and memory device controllers. It also includes drivers and all the essential software needed for the basic operation of the system. What makes an IP platform useful beyond the sum of its parts is that these elements come integrated and pre-verified, and that the resulting system should have already proven itself in multiple real-world products. Beginning an SOC design project with such a platform gives a designer a considerable head start over starting from scratch. A good IP platform reduces risk, decreases development cost, and can significantly shorten the length of a challenging development process. ASIC-Based Product Considerations The benefits of using an IP platform are more clear when one considers the factors impacting a new development project. The most important, of course, is the overall return on investment (ROI), which is affected by marketing costs, manufacturing costs, opportunity costs, and engineering costs. From an engineering costs standpoint, the major considerations are as follows:
Using an IP platform is directly related to reducing the Development Time, Silicon and Software NRE, and Design Resources costs. Let us merge some of these together and focus on Silicon Hardware/Software co-development. In most of today’s integrated products, the critical functions (excluding memory) are inside one or two chips, and the greatest costs by far are in the development of these chips. Since at least one of these chips will contain a microprocessor, developing the software for the processor is also a significant cost. Table 1 examines some typical development costs based on our experience developing dozens of different systems with various processors and for various applications.
Table 1. Approximate breakdown of product development Engineering Costs (based on multiple projects by SOC Solutions). As can be seen in Table 1, when developing a product containing an ASIC, the silicon and software development costs combined are typically greater than 60% of the total development costs. This is a significant investment. Now consider that companies often have product roadmaps and plan on periodically introducing new products. This makes the cost of developing “derivative” products an important consideration in the planning of a product line life cycle. A well-planned product line will make these new development costs incremental by reusing a large portion of the initial hardware, silicon, and software design. Using such a platform strategy is important. Product line planning should also weigh the costs of porting these designs to different silicon vendors and different silicon types (such as FPGA, Structured ASIC, ASIC, ASSPs). As we will see in the next section, the silicon independence of a good IP platform is crucial to keeping these costs and — the associated risks — to a manageable level. Silicon Options The many device technology options for custom silicon implementation can be categorized as FPGAs, Structured ASICs, and Standard Cell ASICs. While there are many variations in production technology — such as .18u, 90nm, 65nm, embedded FLASH and mixed-signal (analog – digital) — almost all new microprocessor-based designs use a similar common architecture: 32-bit processors connected to a 32-bit processor bus subsystem. Table 2 shows a sample of available 32-bit microprocessors for the three device categories.
Table 2. Comparing silicon technologies using embedded 32-bit microprocessors. As can be seen, there are various processor choices at various prices depending primarily on the silicon vendor. The low-priced processor cores are the proprietary FPGA microprocessors from Altera (NIOS) and Xilinx (Micorblaze), and the higher-priced cores consist of various processors from ARM, ARC, MIPS, and Tensilica. Proprietary microprocessor cores offered by FPGA vendors are very inexpensive but can carry a hidden cost in that they are not portable to other device technologies. In contrast, microprocessor cores from independent IP vendors cost significantly more up front, but they are delivered as HDL source code and are very portable. Often silicon foundries or semiconductor companies will subsidize the costs of the microprocessor IP to the customer by supplying “Simulation Models” for development. This can be a trap, however, as the customer is then locked into that foundry for supplying chips. SOC Architectures Have Much in Common Despite being targeted at different application areas and product types, 32-bit processor SOCs tend to have several things in common. For example, most SOC architectures use many if not all of these functions or IP cores:
Acquiring this set of essential cores in a pre-integrated, pre-verified IP platform is intuitively a more efficient approach than assembling them from separate sources and then combining and testing them. Figures 1, 2, and 3 help make this clear by showing the architectures for some existing SOCs and highlighting those portions that might have been rapidly realized by starting with an integrated IP platform. These SOCs have different purposes and implementation details, but the head start coverage a platform can provide for each is obvious. Figure 1. A Philips system design using an ARM720 processor for a general-purpose microcontroller. Besides individual functional blocks or cores, the systems in Figures 1, 2, and 3 also share a similar bus architecture. This architecture is based on an AMBA AHB bus system with the additional integration of high-speed peripherals such as a USB 2.0 controller, LCD controller, or video decoder. Low-speed peripherals such as I2C, IIS, and SPI are also integrated, but on a separate low-speed bus such as AMBA APB. Study of many proven commercial SOCs show this high-speed/low-speed bus architecture to be a common distinguishing factor. An effective IP platform, then, should provide the interfaces and otherwise handle the implementation details needed to exploit this successful architecture.
Figure 2. A Samsung Media Encoder system design using an ARM940 processor and aimed at providing maximum flexibility for advanced portable audio players using hard drives. Figure 3. Chips & Media system design using an ARC605 processor for an MPEG Decoder Chip. Choosing the Right IP Platform Combining the factors just discussed — inclusion of commonly used functions and design using a high-speed/low-speed bus architecture — with other critical aspects leads to this list of critical platform selection factors:
Technology- and device-independence are important criteria in selecting an IP platform. Working with reputable third-party IP partners can help a company avoid getting locked into IP that only works with a particular supplier’s tools or manufacturing processes. This is especially true since many companies release the product to production as an FPGA or Structured ASIC first, with the intent of converting to a Standard Cell ASIC when the volumes reach a level to justify spinning an ASIC. Also, to stay competitive in the marketplace, often the vendors and technology have to change for new products. Choosing a platform that is processor agnostic as much as possible is key to effective reuse. This means the platform should support a variety of similar processors, and work well with each with only minor redesign. Ideally the platform should use a standard, familiar internal bus architecture as its foundation. This reduces re-learning and ensures the availability of a variety of compatible IP cores. Choosing the right software driver code is also important. Most embedded device drivers are written in either C or the assembly language for their particular microprocessor. Rarely are device drivers written in other languages. Since assembly code is not portable from one microprocessor to another, it is critical for reuse and portability that the device drivers are written in C code. There are many good C compliers for the various processors that produce optimized microcode output that is close in efficiency to hand-written assembly. Any true IP platform contains integrated software that was designed specifically for the platform’s SOC design. The integrated hardware and software has to have good support for developing end-product software applications: it’s simply not enough to deliver just boot code and driver code. The integrated software should contain features to support a number of various RTOS or, at a minimum, software kernels or schedulers. The software should also have a good API layer that facilitates the integration of C code application software. Ideally, the software engineer can start developing C applications “right out of the box” without having intimate knowledge of the underlying hardware. Lastly, an effective IP platform has to be proven in silicon, have good prototyping support (usually through FPGA prototyping boards) and should be offered by an established IP provider with a proven track record of delivering quality IP and excellent customer support. Examining an Example IP Platform The characteristics of a flexible, effective IP platform can best be seen by examining one such product, the Pre-Integrated Platform (PIP-AMBA) developed by SOC Solutions, Inc. and available from CAST, Inc. (see Figure 4). This third-party IP platform offers significant advantages over those from processor vendors, EDA suppliers, or semiconductor/FPGA manufacturers. Figure 4. Block diagram for the PIP-AMBA IP platform from CAST and SOC Solutions. Standard Bus and Microprocessor Independence. The PIP-AMBA IP Platform is an integrated SOC reference design built on the AMBA (AHB/APB) Bus Architecture, which is the most common architecture used for 32-bit SOC designs. Not only has ARM Ltd produced and adopted the AMBA bus architecture, other microprocessor IP companies such as ARC, MIPS, and Tensilica have produced processors with AMBA bus interfaces. This widespread support of the PIP-AMBA’s bus makes it straightforward to use the platform with a variety of different microprocessors (specifically those from ARM, ARC, and Cortus/CAST). Proven Independence from Device Technology. The PIP-AMBA was developed primarily for ASIC designs, however, it was also optimized and partitioned for FPGAs. This embraces the reality that most ASIC designs are prototyped in FPGAs for system-level debugging and verification. It is important that the FPGA prototype design be as similar as possible to the final ASIC design, not only for verification but also for easier re-targeting to the ASIC. The PIP-AMBA design hierarchy is modularized to simplify the retargeting of memories, PLLs, I/O, and clock structures. This makes the PIP-AMBA a versatile IP platform for both FPGA and ASIC device technologies. It has been used in FPGA products as well as Structured ASIC and ASIC products, and CAST offers the PIP-AMBA as HDL source or FPGA netlist. Aditional Third-Party IP Core Availability. PIP-AMBA supports most AMBA AHB and APB peripherals. This makes it easy to integrate with the base platform the many third-party AMBA-compliant IP cores. “Right Out of the Box” Software. The platform’s peripheral drivers are written completely in C code (no assembly language). The PIP-AMBA boot code is minimal assembly code which sets up software stacks, interrupt vectors, and memory allocation. The small amount of boot code is easily ported to various processors. The software is delivered with well-written and thoroughly-commented header files (.h files) that make address mapping and customization straightforward. All this means that C code development can begin immediately, right out of the box. System-Level Prototyping and Design Support. Several FPGA prototyping boards are available for use with the PIP-AMBA (one is shown in Figure 5). Deliveries often provide the PIP-AMBA platform pre-loaded on the FPGA development board so that customers can start C code development even before their SOC designs are complete. (SoC Solutions also provides design services to help the customer integrate in-house or third-party IP with the PIP-AMBA platform.) Figure 5. FPGA development board for rapid implementation and evaluation of PIP-AMBA SOCs. Conclusions Designing products that include microprocessor-based SOCs is an expensive endeavor. Care should be taken to create a product line development strategy that leverages hardware and software design reuse, is independent of device technology, and is processor agnostic. Using a pre-integrated embedded microprocessor-based IP platform is key to a economically achieving such a successful product line development strategy. Choosing the right platform can provide a flexible SOC design that can be migrated or adapted across various device technologies and microprocessors with minimal re-design effort, thus saving valuable development time, NRE, and needed resources. For example, the PIP-AMBA platform used as an illustration in this paper has been successfully used as the foundation for an array of successful products and applications, including:
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|
|
Home | Feedback | Register | Site Map |
|
|
|
All material on this site Copyright © 2017 Design And Reuse S.A. All rights reserved. |
