Commentary: Virtual components are more than 'IP'
EE Times: Latest News Virtual components are more than 'IP' | |
Thomas L. Anderson (01/23/2004 6:00 PM EST) URL: http://www.eetimes.com/showArticle.jhtml?articleID=17500886 | |
There are few abbreviations more over-used in the electronics industry than "IP" as an abbreviation for "intellectual property." Let's face it — just about everything we deal with every day on the job is intellectual property. RTL designs, masks, C code, engineering specifications and even customer lists are all IP.
When the Virtual Socket Interface Alliance (VSIA) began to tackle the problem of establishing standards and processes for design reuse, it wisely decided to minimize the use of "IP" in its documents. In light of the continued over-use of this term, it's worth revisiting the topic to draw some importance distinctions.
We at VSIA use the term "virtual component" (VC) to describe a hardware design block that is reused in system-on-chip (SoC) applications. Many questioned, and some still question, the need for a new term. Even today, the terms "cores" and "semiconductor IP" are probably more widely used than "VC" among both VC providers and VC integrators. Yet the original concept of VSIA is still valid — a VC is more than a chunk of hardware design tossed over the wall to a user.
Even a cursory scan of the documents available on the VSIA web site shows that there are many dimensions of effective design reuse. Numerous specifications and standards define best practices for developing VCs and integrating them into SoC devices. Exactly this sort of rigor in design reuse is the essence of the virtual component concept. Any design, any IP block, can be reused with some level of pain. By definition, a true VC is designed, verified, documented and supported for reuse.
Designing for reuse is not trivial; it involves an understanding of potential integrators and the different applications their SoCs will serve. Verifying for reuse, the focus of my VSIA working group, means that the VC provider must anticipate all possible ways that the design will be used and verify that it operates as intended in every scenario. Beyond this, the provider should supply critical verification elements (testbench, test suite, protocol monitors) along with the VC itself and furnish guidelines for reuse of these elements during full-chip verification.
VC documentation must provide details on the design and verification process, such as the level of code coverage achieved by the test suite. Although every internal aspect of the VC's operation need not be documented, it is critical that the interfaces be described in enough detail for the integrator to hook up the VC properly within the SoC. Finally, the provider must offer phone, e-mail and hands-on support as needed to ensure proper integration. An "over the wall" approach does not make for a successful IP business model.
In the mad rush to find revenue in tight times, many companies have licensed IP in various forms to all sorts of integrators. Many consulting companies have tried to reinvent themselves as IP providers to build a more uniform revenue stream. Companies that succeed in the business are those that truly license VCs, not just IP, with the support to back them up. It's not just a VSIA terminology detail; the virtual component concept is as important as ever.
Thomas L. Anderson is a technical marketing consultant. He chairs the VSIA's technical verification development working group.
| |
All material on this site Copyright © 2005 CMP Media LLC. All rights reserved. Privacy Statement | Your California Privacy Rights | Terms of Service | |
Related Articles
- Expanding emulation's reach with virtual devices
- Find out what's really inside the iPod; Reuse of components is a good design practice for similar applications, including mobile handsets
- Electronic musical instruments design: what's inside counts
- How to Turbo Charge Your SoC's CPU(s)
- New Developments in MIPI's High-Speed Automotive Sensor Connectivity Framework
New Articles
Most Popular
E-mail This Article | Printer-Friendly Page |