SoCs: Supporting Socketization -> Verifying cores catches coding errors

Verifying cores catches coding errors
By Michael T.Y. McNamara, Senior Vice President of Technology, Verisity, Mountain View, Calif., Jeffrey J. Holm, Communication Products, LSI Logic Corp., Bloomington, Minn., EE Times
January 3, 2000 (3:23 p.m. EST)
URL: http://www.eetimes.com/story/OEG20000103S0052

Verification is usually misunderstood. People think it refers to high-quality cores, but for socketization the real issue is core delivery. What assumptions about the target system were made? What were the integration rules? How is the core to be integrated into different application domains? How is the integrator expected to verify correct integration, especially if the core is driven strictly by the system and not the ports?

Altogether, the socketization of the tool kit surrounding the core itself should consist of the following parts:

- Checkers: Interface checkers (mainly temporal) will catch in-tegration errors, while internal checkers (of the core's internals) can denote cases where there is a real bug in the core. This makes it easier to support the core in "strange" environments.

- Coverage scenarios: These define the different scenarios the core developer believes the integrator should test, particularly the protocols and important communication scenarios between the core and the system.

- Reports and debugging utilities: Besides allowin g the integrator to get more information about the internal state of the core during a test, these can also be used to supply the core developer a debugging aid when necessary. Note that these reports need not be "readable" to the integrator if there are concerns about the proprietary nature of the internals of the core.

The developer might also want to include with the core other parts of the testbench he developed. This can be useful to show that the core works correctly in a given controlled environment, and can also be used as a reference for the integrator, showing how the core should be stimulated. Additionally, integrators can reuse many of the same testbench modules in the development of their own logic.

Faster starts

Behavioral models and bus functional models (BFMs) are usually used in the development and verification of cores. The behavioral models can often be developed faster than the register-transfer-level code, which makes it possible to start system developmen t sooner. The behavioral models also make the simulations run faster. Since they are easier to control than the real logic, BFMs are usually used to drive the core interfaces.

These behavioral models and BFMs can serve the same purpose for the integrator as they do for the developer. When integrators are developing their logic, they are likely to start with a BFM as well (instead of the core). Rather than having the integrators create their own behavioral models and BFMs, guessing what the correct behavior is from a specification, these should be part of the core developer's deliverables.

It all begins with the intellectual-property developer verifying his core. By using a testbench automation tool like Specman Elite, the developer can make full use of the automated testing approach to generate tests for the core, and cover all its functionality without any required assumptions on the target environment.

The testbench automation tool will generate tests for the core and inject them into the core. The test generation can be done before the simulation begins or on the fly, during simulation. The on-the-fly approach allows the stimulus to be generated just before it is injected. This technique makes it possible for the next input to depend on the current state of the core, enabling the test to reach interesting corner cases.

In addition to generating and injecting the stimuli into the core, the testbench tool should check that the core behaves according to the specifications. The two main types of checks called for are data checks and temporal checks. The data check focuses on the contents of the core's output, while the temporal check focuses on the timing rules (protocols) that are part of the specifications.

The checks created by the core's developer, along with additional new checks focusing on the interface of the core, are made part of the verification tool kit that ships with the core. These checks will automatically fire when an integration rule is violated. When that happens, the simulation will stop immediately and the integrator will be able to debug his design. Each check in the tool kit will be accompanied with a comprehensive description of the problem and possible reasons. Also, the fact the simulation stops at the exact moment of violation is much more effective than discovering the problem only when bad data is seen at the outputs of the core, usually thousands of cycles after the violation.