Coverage driven Random Verification

Coverage-driven random verification methods are becoming recognized as one of the best ways to verify complex IC designs. Cadence Design Systems, announced that new technologies have been integrated into the Cadence® Incisive® Enterprise verification family that enable engineering teams to address increasingly complex chip design. Incisive technologies now offer support for the newly developed Open Verification Methodology (OVM), a new aspect-oriented generation engine, and the second generation of Cadence transaction-based acceleration (TBA) with native support of multiple test-bench languages and numerous productivity enhancements.

To understand how to take advantage of this solution, cdn (cadence designer network) talked to Mr. Apurva Kalia, VP of R&D.

You can read his interview here.

SOC Verification 3

In the last post, we saw the traditional SOC verification approach. In this post, we are going to see the unique approaches in SOC verification. SOC verification becomes more complex because of many different kinds of IPs on the chip. A good understanding of the overall application of SOC is essential. The more extensive the knowledge of external interfaces, the more complete the SOC verification will be.

Verification Planning Guidelines

The following should be considered in the verification planning.

External Interface Emulation When you verify the complex SOCs, you should consider the full chip emulation. The external interface of each and every IPs on the SOC as well as the SOC data interfaces should also be examined. This should be performed simultaneously for all cores.

Unit level to Top level SOC designs are built from bottom to top. The truth is that the unit level must be used in any of the design hierarchy imposes a need to verify these modules in any possible scenarios.

Re-Use the verification components As the leaf modules are assembled to create the SOC, many of the leaf module interfaces are internal interfaces between various modules of SOC, and there is no longer need to drive their inputs. However other interfaces are external interfaces to SOC. If the test generators for external interfaces are independent components, then most system level stimuli can be taken as is from the various module environment.

Many components in SOC can work independently and work in parallel with other components. In order to exercise the SOC in corner cases, the tests should be able to describe parallel streams of activity for each component separately.

Integration Monitors The primary focus of SOC verification is on integration. Most bugs appear in the integration b/w blocks. An integration monitor that comes with an IP can be great help to find the integration problem. It can be hooked in to the simulation environment and just run to see any integration violation appears on the monitor. This can save the time dramatically. This kind of IP monitors can bring lot of benefits in quality of SOC.

Coverage It is important tool for identifying areas that were never exercised. Both code and toggle coverage are the first indication for areas that were never exercised. However they never tell you that you achieved the full verification. Functional coverage allows you to define what functionality of the device should be monitored.

Looking at functional coverage reports, you may conclude that certain features were already exercised and focus your efforts on the areas that were neglected. But most significant impact of functional coverage in context of SOC verification is in eliminating the need to write many of the most time consuming and hard to write tests.

Conclusion The main focus of SOC verification needs to be on the integration of the many blocks it is composed of. There is a need for welldefined ways for the IP developer to communicate the integration rules in an executable way, and to help the integrator verify that the IP was incorporated correctly. The complexity introduced by the many hardware blocks and by the software running on the processor points out the need to change some of the traditional verification schemes.

SOC Verification 2

Traditional SOC Verification

Write a detailed test plan document

We usually write hundreds of directed tests to verify the specific scenarios and all sort of activities a verification engineer can think it is an important. But there are some limitations:

• The complexity of SOC is such that, many important specific scenarios in which the bug might hide are never thought of.
  

• As the complexity of SOC increases, it become difficult to write a directed test that reach the goals.

Test Generations

Each directed tests that we write, check the specific scenarios only once. But this is not advisable. Since we need to exercise these specific scenarios with different combination of inputs, then only we can find the hiding bugs. Many of us write a random test case to find the hiding bugs, but these are exercised only at the end of the verification cycle. Though these tests reach most of the unexpected corners, we will be verifying the same scenarios again and again and still tend to miss a lot of bugs. But what we actually need is to focus on the particular area of interest in the design. So ....... We need a generic test generators that can easily directed into areas of interest.

Integration

Test bench development for SOC design requires more efforts than the design itself. Many SOC verification test benches doesn't have a means for verifying the correctness of the integration of various modules. Instead the DUT is exercised as a whole unit. The main draw back to this approach is finding the source of the problems by tracing the signals all the way back to where it originated from takes much time. This leads to the need for integration monitors that could identify integration problems at the source.

Tape out..... Tape out..... Tape out.....

Every design and verification team needs an answer for the Million dollar question...... When are we ready for tape out?

To answer for this question is very tough as the verification quality is very hard to measure. Every one's answer would be different. My answer would be depends on code, branch, expression and toggle coverage, functional coverage and bug rates. To solve this dilemma, there is need for coverage metrics that will measure progress in a more precise way.

To summarize, there is always an element of spray and pray(luck) in verification, we are hoping that we will hit and identify most bugs. In SOCs, where so many independent components are integrated, the uncertainty in results is greater. There are new technologies and methodologies available today that offer a more dependable process, with less praying and less time that needs to be invested. In the next post i'll explain unique approaches in SOC verification.

SOC Verification 1

The typical System-On-Chip (SOC) may contain the following components. The processor (ARM or DSP), the processor bus, many peripherals like USB and UART, peripheral bus, the bridge which connects the buses and a Controller. The verification of SOC is a challenging one because of the following reasons.

Integration of various modules : The main focus on verification of SOC is to check the integration between the various modules. The SOC verification engineers assumes that each module was independently verified by the module level verification engineers.

IP block re-use : IP reuse was indeed seen as a way to foster development productivity and output that would eventually offset the design productivity gap. Many companies treat their IPs as an asset.

HW/SW co-verification : An SOC is really ready to ship when the complete application works, not just when hardware simulations pass in regressions. In other words, the ultimate test for a chip is to see it performs its application correctly and completely. That means execute the software together with the RTL. So we need a way to capture both HW and SW activities in the tests we write to verify the SOC.

Some of the SOC bugs might hide in the following areas.

• Interactions b/w the various blocks.
• Unexpected SW/HW handling

All the challenges above indicates that we need a rigorous verification of each of the SOC components separately. I'll explain the trends in traditional SOC verification methodology in the next post.