A comment in the GABEonEDA blog entry “Accellera Works Toward a Unified Verification Methodology (UVM)” recently caught my attention:

Silicon respins due to design errors not only have not diminished in number, they have actually increased. This is an indication that complexity has grown more than the ability of verification tools to detect errors.

The article continues by discussing the industry effort led by Accellera and their member companies to improve verification. I attended Accellera’s panel discussion at the recent Design Automation Conference (DAC). DAC’s presentations and products that address verification, as well as other articles and blogs on the subject, illustrate the need in that area.

Verification is just one of many steps in the development life cycle of a product, starting from high-level design, through verification, and on to system test. Tools such as Electronic System Level (ESL) and co-simulations address one or more of these steps, but tools cannot address all concerns.

Effective methodologies, too, are necessary for successful product development. One very important methodology is collaboration between hardware engineers and firmware (embedded software) engineers from the first step to the last, from high-level design to system test. Tools such as virtual prototypes may help engineers collaborate, but tools will not make engineers collaborate.

For example, one infamous collaboration failure was the Mars Climate Orbiter, which crashed because of a metric vs. Imperial units clash between design teams. (More info.) In another notable collaboration failure, Airbus’ A380 jet was two years late and Airbus lost $16 billion because they did not invest to have all collaborating mechanical design teams use the same tool set. (More info.)

Compared to the costs of such failures, collaborative methodologies can be fairly inexpensive to implement. For example, a collaborative methodology could have firmware team representatives review and sign off on hardware specifications and milestones. I saw how this one change alone saved hundreds of engineering hours and thousands of development money when my previous employer implemented this.

In addition to collaboration, here are a few other examples of methodologies that can support verification by eliminating or mitigating design flaws:

Register Layout Standard: Define and implement the same register layout standard across all blocks and in all chips, allowing leverage of verification modules. A standardized layout should include specifications such as which bits are mixed or separated across registers and how bits and registers should be added or deleted across versions. Not only will following a standard help the verification phase, it will also help firmware engineers write consistent and reusable firmware.

Standard Functionality of Common Modules: Define how an interrupt module or a DMA module behaves and use that behavior consistently throughout all blocks and across all chips. Where possible, use the same source files and instantiate them everywhere to minimize entry of defects. A standard verification suite for these common modules can then verify the functionality of all instantiations of that module.

Standard Documentation Format: Use the same standard document format and style for all blocks on all chips. The standard should entail both the correctness and completeness of documentation. Verification engineers and firmware engineers rely heavily on this.

Test and Debug Hooks: Allocate silicon space for test and debug hooks accessible through registers and retain those hooks when going to silicon. Errors found during verification can be corrected before tape out, but once in silicon form, corrections require expensive respins. Since we’re all human, design and verification errors cannot always be avoided. But if a test and debug hook left on the silicon allows firmware to work around a hardware problem, then we can eliminate that defect and still avoid a chip respin.

Albert Einstein said, “Intellectuals solve problems; geniuses prevent them.” Verification attempts to find problems after they’re already in the design. However, by implementing methodologies that prevent problems from entering the design in the first place, we can tap into some of that genius Einstein talked about.