Electronic Design

Leveraging Intellectual Property Gets Easier As Standards Make Headway.

Advances in the creation and "standardization" of IP allow SoC designers to better assemble complex single-chip solutions that work right the first time.

In the creation of system-on-a-chip (SoC) solutions, designers have already accepted the fact that they cannot create every functional block that gets integrated on a chip. Therefore, they must rely on outside sources to provide a number of predesigned functions required to complete their chip design. To meet those demands, there are currently well over one hundred companies, ranging from very small sole-proprietor organizations to Fortune 500 companies, offering some form of silicon intellectual property (IP) for license or sale. Until recently, such blocks carried few details with them about their testability, interfaces, and other information that could define aspects of their functionality and performance.

Formations of industry organizations like the Virtual Socket Interface Alliance (VSIA) help to set standards and guidelines for chip-oriented IP. This has contributed greatly to the improved quality of IP blocks. In addition to setting standards for various aspects of IP, the VSIA meetings serve as a forum to shed light on all of the issues surrounding the creation, use/reuse, interconnectivity, testing, and documentation requirements.

One area not heavily addressed at VSIA meetings relates to various legal issues as well as the sale/licensing aspects of the IP. Along with this comes one of the biggest cans of worms—who takes responsibility for ensuring that the IP block performs as promised on the data sheet? Is it the purview of the IP supplier, the chip foundry, the SoC designer, or some combination of all three?

To some extent, the large foundries are trying to put that issue to rest by prequalifying an IP block before it's added to their library. In a few cases, foundries have set up a rating system akin to the olympics, with gold, silver, and bronze rankings for cores. Gold typically represents cores already production proven. Silver might represent cores that, though verified, haven't yet been used in a SoC design. Lastly, bronze could represent the announced availability of a soft core that hasn't been implemented in the foundry's process.

By noting the status of the core in the IP catalogs, the foundries can forewarn designers regarding the amount of work that might be needed to integrate the core into the SoC. Both the UMC Group and TSMC, as well as LSI Logic and other foundries have such rating programs in place.

Have It Your Way
Cores, megacells, and other IP building blocks are available in many forms, which makes the selection process even more challenging. The most common form in which designers obtain IP is typically the hard core.

A hard core is a physical representation of the desired function in final placed, routed, and ready-to-be-fabricated form. In essence it's a "black box" that has defined inputs, outputs, physical size, fixed functionality, and guaranteed performance specifications. Many companies offer IP blocks in this form because it provides the ability to optimize the internal workings in order to maximize performance and deliver the best performance possible.

Offering a fixed layout, though, ends up impacting other aspects of the IP usage. For instance, the fixed physical layout of the block prevents the foundry from quickly scaling the design as higher-performance processes bank on ever-decreasing feature sizes.

Hard IP is typically designed for production at a specific feature size and with specific process parameters. To move a complex function, such as an embedded processor core or memory array, to a finer-featured process often requires months to shrink, relayout, and reverify the functionality and performance. Many legacy functions, or those designs of IP blocks extracted from older chip designs, fall into this category.

Hard cores can inadvertently limit design flexibility too. The preset physical shape requires that a specific area of the chip be reserved. Additionally, depending on the number of metal layers used, there may be few or no "through-the-cell" or "over-the-cell" routing opportunities. That could cause the overall chip placement and routing tools to expand the chip to accommodate more routing space.

Solving The Legacy Problem
This situation is especially common when legacy functions are being reused. The legacy functions have typically been extracted from an older chip design. Often these don't include many of the newer interfaces or layout allowances that a newer hard core might include. To circumvent that problem, several design-automation tool suppliers have developed techniques that can envelope the legacy blocks with a "shell" that provides a standardized interface. By standardizing the interface, designers can leverage the commonality and easily connect all the blocks to a backplane.

One company, Sonics Inc., has done just that by developing a full toolkit—the Sonics FastForward Integration System. At the heart of the toolkit is a tool called the Core Creator, which adds a Sonics-defined standardized interface to an IP block. Additional design tools include the SOCIntegrator, a tool that configures the connection between the core and the silicon backplane. The silicon backplane provides the defined, high-performance interconnect that the cores attach to ("Tool Suite Is Strong Medicine For SoC Design Headaches," Electronic Design, Sept. 7, 1999, p. 37).

In contrast to the rigidity of the hard cores, soft cores provide almost unlimited flexibility. As their name implies, the cores are software-based descriptions of the functions. The software is typically written in languages like Verilog or VHDL, but also can be in C, C++, Java, and other languages. It can then be modified or used as is. The final software description of the function can be compiled and the compiled code is passed on to logic-synthesis software. By using the cell libraries available to it, the synthesis software will then create the logic equivalent to the software, which can next be laid out, routed, and verified.

To verify the design, simulation tools, such as those offered by Co-Design Automation, allow engineers to perform mixed simulations that contain Verilog, C/C++, System C, and the company's own language, SuperLog. The SystemSIM tool combines some unique software developed by the company—CBlend technology, a parallel instruction optimization architecture, and the company's SuperLog language simulation tool.

The CBlend technology provides multilingual support for C and C++ programming languages, Verilog HDL, while the company's SuperLog system design language provides a single environment for advanced SoC design. The language is based on a combination of C and Verilog with additional language constructs added for interfaces, protocols, and dynamic system modeling. ("System-Level Design Language Promises A Unified, Integrated Design Flow," Electronic Design, July 26, 1999, p. 35).

The choice of the cell library can then be very critical to the success or failure of the project. Many of the foundries offer both a basic cell library that they may have developed or purchased from one of the many IP suppliers, and one or more optimized cell libraries. This can either be "tuned" for high-speed or low-power by soft-switches that the compiler controls, or it may be totally optimized for one aspect or the other. By selecting the library most suited for the application, you can more easily achieve your goals.

Soft cores, when used unmodified, provide plenty of flexibility at the chip level because the physical shape is arbitrary and the synthesized logic can intermix with the other logic. Thus, there aren't routing channel blockages, which permits more efficient layout and routing. With that comes a penalty, however, because the physical layout can potentially change from use to use. Therefore, the absolute peak-performance changes from a guaranteed value with the hard core, to a range of performance with the soft core, to account for different routing delays.

There are actually, though, more benefits than negatives. One of the key additional benefits is the very short time needed to move the function to a more advanced process. This allows designers to reap the benefits of smaller features, lower power, or higher clock rates. Because the software describing the function is totally independent of the process technology used, it would simply be a matter of substituting a different cell library that offers the desired performance.

There's a third type of IP that's a close cousin to soft IP, but more easily allows designers to control multiple aspects of the IP block. This third type of IP is based on software compilation technology. It allows designers to specify various characteristics of the block to be created.

For example, memory compilers, such as those offered by Virage Logic Inc., allow designers to specify the word width and depth, and whether or not to optimize the block for speed or density. Similarly, configurable embedded processor cores—from ARC Cores and Tensilica, for example—allow designers to add or remove instructions, change the size of the on-chip caches, and alter many other aspects in order to optimize the core to the application ("RISC Blocks No Longer A Gamble For SoC Designs," Electronic Design, May 1, p. 81).

Lastly, designers can create their own unique logic functions using the cell libraries to perform physical circuit design. Or, they can use a high-level-language to define the desired function. These proprietary blocks of IP can then be added to the library for future reuse.

In addition, designers that employ field-programmable gate arrays (FPGAs) are heavy users of IP blocks offered by the FPGA suppliers and many partner alliances. Like the blocks available for use in full-ASIC designs, the IP blocks for FPGAs span the entire range from hard macros to soft cores and compilable functions. The main difference is that you can see the results of your design efforts in days or hours. This is preferable to the usual two or more weeks for first-engineering prototypes.

Both Analog And Are Digital Needed
Although digital system building blocks—memories, processor cores, serial and bus interfaces, etc.—dominate the IP marketplace, there are a number of companies offering mixed-signal and analog building blocks. Such blocks—analog-to-digital converters (ADCs) and digital-to-analog converters (DACs), amplifiers, comparators, line drivers, video interfaces, and more—provide the "real world" interface to the mostly digital SoC. These blocks bring their own design challenges to the world of IP because analog parameters are much more sensitive to variations in processes and layout (see "When Analog And Digital Must Meet: Easing The Integration Of Mixed-Signal IP," p. 92).

But when these mixed-signal blocks are co-integrated with the digital functions, testing and debugging the final silicon is much more difficult. In fact, testing and debugging any SoC design has become a challenge to ingenuity as highly integrated designs often don't provide access to deeply embedded functions. Built-in test schemes, serial data access via JTAG or other test ports, and other approaches help provide the visibility needed to ensure proper operation of the chip.

One company that's trying to address the issue of testability, First Silicon Solutions, has developed an on-chip instrumentation scheme that leverages supersets of traditional debug blocks. The technology developed by FS2 allows designers to handle mixed buses and multiple memories, and permits designers to control the integrated peripherals. Multiple processor cores also can be handled by the instrumentation tools. The debug results emerge in the form of a fast data stream that can be captured and decoded to analyze what the "buried" IP blocks are doing.

One of the key issues concerning an IP is ensuring that it's reusable. Logic or mixed-signal functions can be tuned to fit a particular application. Some aspects of the circuit design, however, could have to change to further enhance the reusability of the function. Tolerances may have to be relaxed. Extra test circuits and more options for connectivity might need to be added as well.

The other aspect of creating your IP lies in how much value you can put into the block versus purchasing a block with similar functionality from an IP supplier. Instead of trying to recreate well-understood interfaces and functions like memory blocks, PCI master/slave controllers, I2C controllers, FIFO buffer memories, and even microprocessors and microcontrollers, these should mostly be licensed or purchased. But, where you can add value by creating blocks with unique functionality, that's the area to expend maximum effort.

According to Qualis Design Corp., the key aspect in design reuse is trust. A trustworthy block should be functionally correct, properly packaged, documented, and most importantly, maintainable. This applies to cores or IP blocks used in ASIC designs and also in designs based on high-density FPGAs.

When a new IP is needed, the designers of the SoC can either create it themselves or find an IP supplier willing to create the block. One new approach to finding such a supplier is the intellectual capitol exchange website developed by HelloBrain.com. The way it works is simple. The company in need of service or the consultants and manufactuers that offer a service can post their needs or skills on the website. They wait for the other company to spot their service or need and bid for the job. Once buyers and sellers agree on the terms, all of the conditions are brokered electronically.

Working Out The Details
As part of the challenge to properly define and specify IP blocks, the VSIA has set up a series of working groups to attack various aspects of IP creation and reuse. In conjunction with VSIA, the RAPID Associate Group promotes the use and acceptance of IP products and services, thus placing more IP into the hands of design engineers. The RAPID Group hopes to accomplish that by working with EDA tool suppliers and semiconductor vendors. This involves driving the resolution of common requirements to help better define every individual IP block and create an "expectation" of what information should accompany each one.

The efforts of the VSIA have led to the creation of multiple development working groups (DWGs). Each of these DWGs focuses on a different aspect of ASIC design. For instance, the On-chip Bus DWG has developed a virtual-component interface (VCI) standard that defines the bus interfaces and related protocols, which should be used for the effective reuse of virtual components. Another DWG has drafted a specification that defines the data formats and the list of deliverables that should be used for structural, performance, and physical modeling of both soft and hard virtual components.

For analog and mixed-signal components, another DWG has come up with a specification that defines the deliverables. It's a design guideline and data format to facilitate the test, exchange, and integration of process-specific "hard" mixed-signal virtual components. Such blocks include functions like ADCs and DACs, phase-locked loops, and many others.

To enable a better chip-level solution, another DWG has concentrated on developing a specification for the attributes of an on-chip bus. The specification provides a detailed description of the requirements for on-chip buses. That includes documentation, physical deliverables, and technical bus attributes. It also describes a set of attributes for system integrators, virtual component developers, and bus developers.

Just released is one more standard from the DWGs. It's a system-level interface behavioral documentation standard. This document provides a description of the mechanisms needed to assure the complete description of communication at various levels of abstraction. It allows designers to separate the virtual component's behavior from its communications protocols. That eases the reuse of the same behavioral block with different interfaces.

Still other DWGs are focusing on several additional issues. One is a guideline for test-data interchange formats. Another is a specification for virtual-component transfers. A third covers the VSIA system-level design-model taxonomy. Defined by this taxonomy are the nature, the uses, and a complete and consistent terminology for a wide range of different virtual-component models at all levels of abstraction.

By leveraging all of these standards and guidelines, designers should be able to create highly reusable IP blocks that can readily be co-integrated on a single chip. Complementing this effort, the RAPID Association, Campbell, Calif., focuses on more commercial aspects. These include increasing IP quality, standardizing the IP delivery format, protecting IP by determining the necessary technical and legal solutions, and then creating acceptable solutions for the IP customers and providers. Also, the group will try to make access to IP easier and raise the awareness of IP's value.

Working closely with RAPID as well is the Virtual Component Exchange (VCX), Livingston, Scotland. The goal of the VCX group is to create a safe, efficient marketplace for IP, which the organization expects to reduce the time to market for new products and potentially lower overall costs.

Further, the RAPID Association and VCX have formed some joint task forces to share ideas and expertise on three key industry issues: creating effective business models for IP companies, creating and using Internet-based IP identification and qualification, and creating licensing models that provide benefits for both providers and systems companies.

Aside from the finger-pointing that takes place when a design doesn't work the first time, the legal issues surrounding IP usually revolve around the licensing/purchase of the IP. Several options now typically exist with IP. Designers can ink a deal that gives them unlimited use of a block across multiple SoC designs. Or, a license might just cover the use of the core for a single SoC implementation.

Additional license variations could involve the licensing of hard cores versus soft cores, royalty plus upfront fees, and many other options. The decision as to which option to go with is extremely application-dependent, due to the fact that the application will determine the potential sale opportunities and, hence, the volume of usage.

Companies Mentioned In This Report
ARC Cores Inc.
(408) 360-2120

Co-Design Automation Inc.
(877) 626-3374

First Silicon Inc.
(503) 645-9591

(408) 987-8900

LSI Logic Corp.
(800) 574-4286

Mysticom Inc.
(650) 210-8080

Qualis Design Corp.
(503) 670-7200

(408) 341-8966

Sonics Inc.
(650) 938-2500

Taiwan Semiconductor
Company (TSMC)
(886) 3-578-0221

Tensilica Inc.
(408) 986-8000

(408) 437-8762

UMC Group (USA)
(408) 523-7800

United Microelectronics Corp.
(UMC) Group
(886) 3-578-2258

Virage Logic Inc.
(877) 360-6690

Virtual Component Exchange
+44 1506 404 100

Virtual Socket
Interface Alliance
(408) 356-8800

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.