SoCs: Supporting Socketization -> Methodology key to quality

Methodology key to quality
By Warren Savage, Director of Engineering, Design Reuse Business Unit, Synopsys Inc., Mountain View, Calif., EE Times
January 3, 2000 (3:18 p.m. EST)
URL: http://www.eetimes.com/story/OEG20000103S0050

Intellectual property (IP) reuse is a key part of improving productivity for system-on-chip (SoC) designs. Although IP reuse has been explored both technically and as a business for many years, only recently have systematic approaches based on EDA technology emerged.

The key-feature planning phase is composed of the necessary marketing and engineering research to clearly understand the product requirements needed for the IP before the design begins. To defer those decisions until later serves only to slow d own subsequent phases by hopelessly tangling implementation and cost decisions with requirements issues.

The design-planning phase involves the development of three key documents: a functional specification, the development plan and a schedule. The functional specification is a "black-box" view of the IP. A strict requirement of the specification is that it possess no implementation details. At this phase, the engineers must not concern themselves with implementation, but rather concentrate on describing functional behavior so the design team can decompose this abstract view of the design into subdesigns (units) to be implemented later.

Basically, the development plan is a management document that describes in great detail how the project will be executed. It details required resources, expected expenses, coding conventions and verification strategies.

By the end of the design-planning phase, sufficient detail about the IP and how it will be developed will be available to create a d etailed schedule. Schedules are typically written using Microsoft Project or similar project-management software to capture a breakdown of the work structure into a series of linked dependent tasks.

The first activity of this phase is to create an implementation specification for the design unit and a test plan. Before register-transfer-level (RTL) coding can begin, the engineer must have completed the design of the unit at the microarchitectural level and written a test plan describing how it will be verified as a standalone unit. The RTL code is then written and entered using the GNU Emacs text editor, a programmable editor with language-specific modes that automate and enforce a standard set of coding conventions. At Synopsys, RTL code is written with strict adherence to the conventions defined in the Reuse Methodology Manual (RMM), coauthored by Synopsys and Mentor Graphics. HDL code linting tools, such as Leda Proton, assist with this task.

Another part of the implementation phase, unit -level verification, is usually done with a small throwaway testbench with which the engineer exhaustively tests the unit prior to integration with other units into the top-level IP block. A code coverage tool provides a quantitative measurement of how well the tests are exercising the code.

Design reviews are the final step in the implementation phase, where all the previous work is reviewed by the IP team. Exceptions to the RMM rules are rare. When they occur, the engineer presents the justification for violating a rule to his peers, who either make suggestions for eliminating the exception or grant a waiver for it.

During the integration and verification phase, the various sub-blocks (units) of the IP block are assembled and intensive verification begins to test the IP block as a whole system. At Synopsys, the block is instantiated in a Vera testbench. The Vera testbench yields a high-level, object- oriented programming environment designed specifically for verification and contains faci lities for self-checking. Self-checking testbenches are used wherever possible to minimize the manual inspection of waveforms. Built-in support for random testing is also important, as is the ability to probe internal points of the IP without adding ports to the top level of the RTL. This methodology also gives the engineer a single-source testbench for both VHDL and Verilog, instead of different ones for each.

Corner cases

Verification activities consist of the development of functionality tests to verify the basic operation of the IP and ensure compliance with any pertinent standards. Deep-corner cases are invoked to verify the correct functionality of the IP under unusual operational conditions. Finally, random testing is used to address nonobvious operational conditions that may not be covered by the corner cases, and silicon prototyping ensures that the IP blocks work in silicon prior to release.

Next, synthesis testing tests the IP under a variety of circumstances to ensu re it will synthesize and meet timing parameters in any number of technology libraries and configurations. This strategy pays off for end users by greatly increasing the odds that the IP can work at maximum speed and minimum area in a range of technologies.

The final phase of IP development, productization, involves the assembly of all the deliverables associated with the IP into a cohesive package that allows the customer to use the IP with the least amount of effort. It must possess functional correctness and the means to allow users to synthesize the IP block and instantiate it in their designs. Users must also be able to verify the functionality of the IP block once it is instantiated in their design. Comprehensive user documentation is also necessary. And to be fully accepted in the marketplace, IP must be supplied in both Verilog and VHDL.

Future research in this area, from both a tools and methodology standpoint, will involve reducing the overhead associated with the design of IP bloc ks. The ultimate goal is to enable nearly all of an engineer's output to be reused with a minimum of extra effort.