SoCs: Supporting Socketization -> Methodology key to quality

Synopsys engineers have been using new methodologies to socketize (productize, package and deliver) complex IP blocks within the DesignWare Foundation library. While the methodology described in this article concerns the particular processes used by the DesignWare development team, these principles and processes are applicable to any ASIC design team.

Reuse is not a new concept. Software engineers have reused code for decades. However, IP reuse for hardware systems differs in one very significant way from its software sibling: The stakes are much higher. Unlike software reuse, where in most cases the functionality of the reused component is evident when the program is c ompiled and run, the real test for hardware IP is fabrication-a leap-of-faith decision where $500,000 to $1 million in nonrecurring engineering charges can be lost in the blink of an eye. There is a need, therefore, for a systematic development methodology for IP that dramatically improves the likelihood of first-pass-functional silicon.

The flow for creating reusable IP consists of a sequence of steps: key-feature planning, design planning, implementation, integration and verification, and productization. Equally important to a systematic design process is a set of tools that enables engineers to create quality IP in a timely manner.

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.