Post a Comment
Third-party components: easing the verification burden
Whether you call them intellectual property, virtual components, or reusable blocks, third-party components diminish their worth by increasing the verification burden. You have to see this fast-moving target quickly and verify it thoroughly.
By Gabe Moretti, Technical Editor -- EDN, 11/23/2000
|
 |  |
It seems like every time we find a silver bullet it misfires. A new industry has developed to answer the pressure of better, faster, and less expensive engineering designs, promising that design reuse will significantly decrease both development time and cost and resulting in better products. Like any new industry, this one more closely resembles the Wild West than a structured commercial endeavor. Small companies, often comprising nothing more than a handful of engineers with a single design, make up the majority of vendors. The industry has no established commercial patterns, and success stories are few and limited to specific types of IP (intellectual property). Reality so far has not supported the assumption. In most cases, design verification, which now consumes 50 to 80% of product-development time, uses the development time that design reuse saves. Lawyers, who are forced to invent new contracts terms for purchasing and using IP, use the rest of the savings. Many factors contribute to the high cost of design verification, and you can avoid most of these factors by changing both technological methods and business practices, but you can make neither of these changes instantaneously or painlessly. IP vendors and early integrators are trailblazers, inventing and establishing a development-and-verification methodology to support reliable and affordable design reuse. Verification costs are high because verification is difficult and time-consuming. Novas, a company that specializes in debugging technology, reminds us that verification is the process of stimulating a design, detecting a problem, finding and isolating the source of the error, and then fixing the error.
Design and implementation bugs are intrinsic to human products, but using better tools and new methods can diminish the number of bugs and their seriousness. All engineers are familiar with the saying, "Do it right the first time," but many factors get in the way of following such a wise principle. Doing it correctly enough and just in time is an expensive but frequent compromise.
Clearly, it is faster and less costly to avoid a problem in the first place or to find it as soon as possible. Any amount of redesign significantly impacts both schedule and costs, but localized changes are less expensive and more likely to be viable earlier in the design cycle. Design reuse and platform-based design are approaches meant to shift costs to the front end of the design cycle, thus significantly diminishing overall product cost by successfully targeting verification costs. As new methods and tools develop, less verification is necessary, and required verification is less complex.
Design for reuse is the obvious method of decreasing verification costs. But it is neither free nor widely accepted. Most people agree that designing for reuse is likely to reduce verification costs, sometimes dramatically, in future designs. But the method requires time and effort to design a portion of a product for reuse. It may entail developing a parametric model, building test structures into the logic, or developing detailed user documentation, and it often requires all three strategies. Companies generally reward product-marketing managers and development teams only if their products are successful. This reality means, above all, that you must meet the market window and not overrun the project budget. Because design for reuse requires an initial investment in both time and money, the common reward model discourages such methodology. No company has rewarded an employee for missing the market window or lowering returns while developing reusable blocks with a view of improving margins in future products.
Some large system companies have dedicated departments for making designs reusable and distributing them within the enterprise. Such a strategy is costly, because taking a functional block of logic that a third party developed without reuse in mind and transforming it into reliable IP is both difficult and time-consuming. The fact that system companies are willing to entertain such investments underscores the need to reduce the risks inherent in SOC (system-on-chip) verification.
To establish an affordable design-reuse methodology, companies can borrow from software engineering. System companies have been reliably reusing software for nearly 50 years: They invented the subroutine, which is the quintessential example of reusability. Modern programming and hardware-description languages have changed the subroutine's name to function, module, and procedure, but the subroutine's intent has not changed. A subroutine is generally reusable, readable, understandable by someone other than its author, parametric, and verifiable independently of the rest of the design. Establishing good methods and following procedures that managers can measure and audit are fundamental tools that lead to high-quality designs. DCM Technologies is a consulting and IP company that started in software and has entered the hardware-IP market. Representatives of the Software Engineering Institute have audited DCM's software-development methods using the CMM (Capability Maturity Model) tool. You can compare both engineering and management processes with the CMM to measure an organization's capability for producing quality products. Observing that many hardware-development methods are similar to software-development methods, DCM Technologies has applied the same CMM process to its hardware development. The result is a net gain in quality and a lower cost for each project at the expense of a nonrecurring, albeit nontrivial, initial investment.
In 1998, Michael Keating of Synopsys and Pierre Bricaud of Mentor Graphics published the Reuse Methodology Manual, which documents a working IP-reuse methodology developed by their two companies (Reference 1). At its publication, the book received much attention from both the press and the industrial consortia. Yet, two years later, almost no one mentions the book as a guide for IP development or reuse. Interestingly, Mentor Graphics asserts that IP verification constitutes only 50% of IP-development and -qualification costs: The company continues to use the methodology that the book describes. A surprising number of companies have no repeatable, measurable method for IP qualification and verification. Having and using a methodology are fundamental to successful and less costly IP verification. The IP industry is young, and experimentation is not just understandable but required to find optimal solutions. But system design has a long history, and qualification and reuse of IP is part of system design. Unless you manage IP from a system point of view, reuse will be costlier and more difficult than necessary.
The VSIA (Virtual Socket Interface Alliance), an organization with more than 170 member companies, adopted the Reuse Methodology Manual when it was first published. In addition, it issued guidelines and specifications for IP and established a working group on verification and verification reuse. The working group aims to publish reference documents on verification terms and methods, followed by a specification for verification deliverables from the IP provider to the integrator. VSIA believes, as do many companies involved in design reuse, that reuse of the verification testbenches is as important as the reuse of design blocks.
Most companies discuss SOC issues only in terms of hardware. Yet most systems combine software, or firmware to be more exact, and hardware. Thus, when dealing with IP verification, you must include software, such as real-time operating systems, device drivers, and protocol handlers. The verification triangle is as dangerous and mysterious as the Bermuda Triangle (Figure 1). IP providers must verify that their products do what they intend them to do. In the case of hard cores, these providers must also work with the foundries to obtain the optimal layout for the targeted process. More important, they must understand their designs' sensitivity to process variations. System integrators must verify that the IP performs as they expect it to; in the case of soft and firm IP, integrators and manufacturers must verify that the optimization does not negatively impact the functions. Now, verification is localized at the vertices of the triangle; the industry must extend the methodology to cover the entire triangle. Methods that support and encourage a team approach would ensure that all parties involved can safely collaborate while respecting each other's rights. Toshiba agrees that the best verification is avoiding the need to verify by building correct-by-construction IP. The company suggests that foundries and designers collaborate in picking the EDA tools that fit both the manufacturing process and the application area. Both established and new EDA companies are addressing the verification bottleneck; new tools will foster new methods and vice versa.
IP development
IP companies tend to look at their products, or "cores," as stand-alone components to be sold off the shelf, whether in soft or hard form. Although such a position simplifies the legal aspects of commerce, in most cases, it greatly complicates verification. Soft and firm cores are distributed in source code, generally at the RTL (register transfer level) and are meant to be synthesized with the rest of the design. Customers can modify soft cores and can retarget firm cores only to a new process or foundry. Hard IP is like a megacell that has been manufactured for a specific foundry and process; therefore, system integrators cannot modify it. Most IP vendors, especially small ones, prefer to deal with hard cores because using hard cores means their IP is protected. Because you cannot modify the product, you can make a definite statement about its functions and manufacturability. All that the author of a soft core can state about its quality is that it works as intended at the time of shipment. Once a soft core is in a design, system designers are likely to modify it, and both soft and firm cores undergo optimizations by synthesis and place-and-route tools that vendors have not tested. The inherent advantage of soft cores—their malleability—is also their major disadvantage in verification, because system integrators must develop test suites that handle these cores as newly designed logic. The verification problem is only marginally simpler with hard cores. When you develop a hard core, it is practical to develop a test suite that verifies its intended function as a stand-alone block. It is more difficult to predict how the core will be used in a system; therefore, most IP providers do not sell system-level testbenches with the core. Although IP developers use commonly available verification tools, some are implementing new methods and tools that are specific to the development of reusable cores, based on previous, often painful experiences.
LSI Logic is addressing the problem in a number of ways. It has established coding guidelines for designers developing hard cores for its processes. LSI Logic uses Vega, a tool that provides feedback about design characteristics likely to impact silicon implementation, such as hierarchy, clocks, buses, and registered outputs. LSI Logic accepts designs targeted to become commercial cores at only the cell-library netlist level. The company's experience has shown that, given code at the RTL, there is no way to predict how the design will function at the silicon level. It strongly feels that foundries and system integrators must work together as a team to ensure the successful use of IP cores. Combining both the verification experience of foundries with systems designers' knowledge of the final product's functions is the only way to produce a good verification strategy.
In addition to providing tools for system integrators, Verisity works with IP developers to provide tool kits the company can deliver to its customers. The tool kits provide checkers and coverage capability that are pertinent to integrators' applications. They are typically configurable for soft IP customized for an application or hard IP when you are using only portions of their capabilities. The tool kits enable integrators to access error messages from the checkers and to coverage information that can help identify problems in the integration and holes in the system- or chip-level tests. They contain complete documentation, executable checkers, coverage scenarios, and a version of Verisity's verification product Specman Elite—called Invisible Specman—that does not require IP integrators to learn or purchase Specman Elite. LSI Logic ships Invisible Specman with all of its CoreWare products.
Synopsys sells both cores and tools to develop cores. The company strongly believes that IP designers must follow good methodology. Simplifying the need for verification is the only way to reduce its cost. The Technology Checker from Synopsys enforces a predefined HDL methodology. Customers can either follow one of the Synopsys-defined methodologies or define their own. Synopsys also believes that end users should not try to modify soft cores but instead that, original vendors should make the necessary changes. Synopsys ships CoreBuilder with every IP core it sells, because it believes that integration is the responsibility of IP creators. CoreBuilder is a synthesis-scripting and configuration engine for system integrators. The product runs synthesis "under the hood" to give optimal core instantiation, given the surrounding logic, and generates a testbench for functional verification.
Mentor Graphics sells both IP in source code and consulting services to IP developers. In developing its own cores, Mentor Graphics has found that a verification plan must be an essential part of the initial specification. The specification is written in either C or C++, following predefined guidelines. Even with all these precautions, ambiguity creeps in, complicating the verification task. Although Mentor Graphics sells IP in source code to allow silicon optimization, it warns its customers that the physical-synthesis optimization could destroy functions, putting the onus back on verification. The consulting arm of Mentor has found that it must customize its workflow to each customer. It believes that although platform-design methodology is addressing some verification issues, the inherent rules are likely to take away some designer creativity.
One company that specializes in DSP cores, 3DSP, sells only soft cores and improves system performance by improving the performance of the interface with the rest of the system using good placement planning. The company addresses the verification problem on two fronts: It delivers to its customers a cycle-accurate simulator written in C and provides consulting help with both synthesis scripts and place-and-route decisions. In-house verification uses millions of random vectors to simulate interrupts, cache misses, and random data before the core is certified for shipment.
You can design IP cores for testability to help with verification. Such a strategy, of course, increases device size, but the increase is negligible when you are dealing with million of gates. Syntest Technologies offers a suite of tools that helps logic designers build fault-free and testable circuits, as well as tools to generate test vectors for circuits. LogicVision sells Embedded Test Solutions, a product that analyzes the core netlist and generates test logic for both verification and manufacturing testing.
Verification problems become even more complex when they involve analog cores or cores that contain both digital and analog portions. Analog cores depend on process technology and the placement of the core within the SOC. Mysticom is an IP vendor specializing in communication applications, specifically Ethernet cores. During core development, it performs block-by-block verification as well as a complete interoperability test when the core is finished. It can take advantage of test sequences derived from the standard specifications of the various Ethernet protocol levels, but such tests are still time-consuming. Mysticom provides customers with a multichip-module sample of the core to aid functional verification. It also establishes physical and electrical rules to ensure that the design of the rest of the system does not affect the analog portion of the core. Mysticom also provides layout guidelines to help meet Federal Communications Commission rules and gives customers a reference design to provide guidance during verification.
Antrim Design Systems has released Antrim-ACV, a mixed-signal design-and-verification product that is useful to analog-IP creators. It not only supports traditional verification of schematics based analog circuits, but also translates the schematics into a behavioral model that you can use to run sweeps to cover corner cases, the least obvious and most expensive behavior to test. System integrators can perform functional verification of both analog blocks and whole designs using the behavioral model. You can easily reconfigure the behavioral model using templates that contain all the specification parameters for the circuit. You can archive the templates, providing lasting documentation and reusable test suites.
IP integration
A system designer's task starts at the architectural level when he or she partitions the system into various functional blocks containing both software and hardware modules (Figure 2). At this point, the seed of errors and inefficiencies are sown. Therefore, the verification task becomes more or less demanding, depending on trade-offs you make at this stage. Cadence Design Systems has introduced VCC (Virtual Component Co-design), which assists architects in analyzing the consequences of various design partitions in the functional, timing, performance, and interface domains before the design of the blocks begins. The tool is new; therefore, it has limited exposure in the field, but it promises to significantly impact verification costs by preventing design bugs, which are the most expensive to find and fix. At the early stages of the design, VCC also helps in determining which IP cores are candidates for inclusion in the system you are designing, thus improving the evaluation process.
CardTools' NitroVP is a co-design and cosimulation environment that also helps to eliminate design errors and verify SOC designs by prototyping the entire design and co-simulating it on a single platform. You can perform the evaluation at a level of abstraction high enough that you identify design errors as early as possible and thus decrease verification costs.
One of the most time-consuming aspects of SOC design is the evaluation of third-party IP cores. Generally, before the evaluation can even begin, both parties must generate legal documents. In the case of soft IP, users might have to pay a significant amount of money before vendors make the code available. Simutech, in conjunction with the ISLI (Institute for System Level Integration) at the Alba Centre in Livingston, Scotland, offers an evaluation method that is secure for both vendors and IP users. The vendor provides a version of the IP on FPGAs (in the case of soft cores) or on bonded-out chips (in the case of hard cores). Simutech provides its Rave prototyping product, and ISLI provides the facilities and administration required to allow third parties to use the IP prototype without having access to the actual IP. Using this method, system designers can verify the functions of IP in the system before they issue a purchase order for the IP.
Aptix provides essentially the same service through its www.eSoCverify.com portal. Using a secure Internet connection, customers can evaluate, integrate, and verify an IP block that is part of the Aptix certified-IP library. You can remotely exercise the cores, which are mounted in Aptix's System Explorer prototyping product, together with the rest of the system prototype.
Altera allows its customers to evaluate the cores in its portfolio by downloading an executable file that is compatible with the Altera OpenCore tools. This ability allows users to simulate the IP without being able to program it into an FPGA. The simulation model contains only typical timing. Clear Logic offers a product that can also provide best- and worst-case timing for the core simply by reading the bit stream that Altera provides.
Once you have evaluated and chosen the IP, you must verify it with the system prototype at various stages of development. Core developers almost always test IP to ensure that it works as advertised. Because vendors have little knowledge of the system in which you will use the core, they do not perform a functional system test. The different expectations of vendors and users are a source of verification problems. The ASIC Alliance, a consulting company specializing in IP integration provides its customers with a verification environment that looks at the IP from the system point of view and generates the appropriate scripts, make files, and test vectors to verify the IP within the system.
Quickturn joins with both Altera and Xilinx to allow users to verify cores by downloading a programming file from a Web site and then using its RPS (Rapid Prototyping System) product to verify the design. If the core requires more than one FPGA, it uses the Synplicity Certify product to partition the design. System integrators that want to put large, soft cores or entire designs onto multiple FPGAs can also use Certify.
Mentor Graphics' Seamless CVE (Co-verification Environment) product supports co-verification of hardware and software blocks. It dynamically optimizes simulation performance by executing either in instruction-simulation mode or actual hardware mode. Designers can use actual code in the target system to exercise the simulator instead of developing test vectors.
As the SOCs grow to more than 1 million gates, simulation acceleration and formal verification become the only practical methods to verify entire designs (Figure 3). Axis and Tharas Systems are addressing the acceleration problem, and Verplex provides formal-verification tools. Accelerating verification allows designers to use many more test vectors, which the system integrator can generate algorithmically instead of manually generating test cases. Axis offers the Xcite and Xtreme hardware-accelerator products. Xcite is a self-contained Verilog simulator in a box that offers simulation-specific architecture to improve performance. Xtreme maps Verilog statements into Axis-proprietary executable primitives and can emulate as many as 20 million gates. You can also connect Xtreme to an external prototype system, thus further increasing both the verification capacity and the speed. Tharas Systems provides the Hammer accelerator, which works within the Verilog simulation and debugging environment already available to its customers to eliminate retraining costs. Its accelerator uses ASIC devices instead of FPGAs, and networking protocols instead of traditional buses to increase performance. It has shortened simulation times on some customer designs by a factor of more than 200.
Verplex provides formal-verification tools at three levels of design abstraction. BlackTie is a functional checker that verifies design intent. It uses a mechanism similar to VHDL Assertions, thus avoiding the traditional problem of defining rules in a quasimathematical notation. The difficulty of using previous functional checkers prevented their acceptance by designers. BlackTie automatically generates assertions and also allows designers to enter their own. Tuxedo comes in two flavors: One checks the logic equivalence between the RTL and a design's gate-level representation, and the second checks the logic equivalence between gates and transistor-level implementations. Because formal verification uses no test vectors, execution times are orders of magnitude shorter than comparable simulation times.
Of course, no single silver bullet exists. Successful designers will verify designs using a collection of the above methods and tools. The choice will depend on the mix of hardware and software in the SOC, the complexity of the cores, and the number of times a core has already been used in similar designs and with the same process. Advances in EDA tools, design methods, management awareness of quality and the cost of its absence, and professional education must continue. Together, they might one day comprise a silver bullet.
Author info
 | |
You can reach Technical Editor Gabe Moretti at 1-303-652-0480, fax 1-303-652-0479, e-mail gabe@dimensional.com.
Reuse Methodology Manual, Mentor Graphics, 1998.
