Testbench architecture validation is process to check if it meeting the verification requirements. Additionally check for inconsistencies and complexity. In some cases complexity may be necessity but validation should ensure that complexity is manageable.

Review

It’s important to validate the testbench architecture. Review is one of the very good tools to do effective architecture validation. Even when it’s not possible to get inputs from reviewers a self review is also equally valuable. Some tips for conducting the review are following.

One of the effective ways to validate the architecture is to run through the key categories of the features from the verification plan.

For each of selected feature from different categories such as normal operation, error injection, control command events etc. go through the flow of how test bench handle it. Pay attention to complexity and consistency. Also this sets background of required information for reviewer to ask the questions.

Following are some of the questions to ask to validate architecture from test plan, checks plan and coverage plan perspective.

Use test plan to question:

What does test needs to do to create the scenario? Whether the necessary concurrency required is supported? Can the required synchronization to cause stimulus at right point is available? Are all-necessary error injection supported? Are the various delay injected controllable? How to stop and start the traffic? Is the necessary initialization bypass mechanism in place? Can the timer be shortened? How about reset in the middle? How about asynchronous event handling?

Use checks plan to question:

Which components will implement the checks? Is scoreboard capable dealing with the exceptions? Is the end of test capable of handling various scenarios being reviewed? How the division of checks between the BFM and test bench managed? What is plan for validation of checks functionality itself?

Use the coverage plan to question:

What is the mechanism for functional coverage collection? How to validate the sampling of the coverage? Are the necessary events for coverage sampling in place? Can the functional coverage be disabled? Is functional coverage sufficiently abstracted from test bench?

There should not be inconsistency in terms of interfaces, way of handling verification requirements for related features. If there are any inconsistencies found, they should be addressed.

Detailed the validation of architecture improves its chances of its success. This validation also allows insights in to weakness and parts of the architecture that are not clear or well understood.

It’s important to do periodic post mortems of the architecture choices when difficulty in implementation is faced. Even if the current architecture cannot be fixed it serves as inputs for the architecture next time or when overhaul opportunities come in.

Rapid prototype

Another approach to validate architecture is to quickly prototype few initial features to gain insights of whether it will fulfill the requirements. Either discard or salvage this rapid prototype along with the learning’s to build the right test bench architecture through iterations.

This approach can be useful for the novel designs. If this approach is followed it’s important to minimize the initial investments. Invest in the core features to be evaluated and minimize investments in beautifying the code.