According to MSDN,  “Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application”.

The test bench architecture definition is also not radically different from it.

Architecting test bench is a four step process.

The first step is understanding the prerequisites. These prerequisites set the requirements for the architecture.

The second step is dividing the functionality to various components meeting the requirements and mapping to the classes.

The third step is validation, to check if the architecture has any inconsistencies.

Fourth and the final step are architecture delivery to execution by packaging it in documents and abstract classes.

Step 1: Testbench architecture : Prerequisites 

There are four key prerequisites that provide the requirements for the test bench architecture process.

• Design under test (DUT)
• Verification plan
• Application world abstraction
• Reuse strategy

 

It might seem tempting to directly jump into the test bench architecture with partial understanding of the prerequisites or even skipping some.

Especially it’s tempting to skip writing the verification plan. It takes time and effort to come up with a good verification plan containing test plan, coverage plan and checks plan but do not skip it. This is one of the very important prerequisites, as the primary objective of test bench architecture is to meet the requirements of the verification plan.

Verification plan also serves as means to validate the architecture. Bottom line, test bench is the means to execute verification plan. So a test bench architecture without a verification plan is strictly no. Please don’t.

If you do break this rule, remember payback will be in the form of longer time to close last 20%.

Step 2: Testbench architecture : Abra ka dabra 

Are you wondering why is this step named “Abra ka dabra”?

That’s because, after all preparations, when a great architecture emerges out, it almost seems like a magic. It just beautifully handles all the cases, even the cases that were not anticipated. It’s a pure joy to watch it in action.

Following are the steps to completely build the test bench architecture.

• Functional division
• Selection among alternatives
• Handling concurrency and time
• Handling ambiguity and inconsistency

Step 3: Testbench architecture : Validation

Test bench architecture validation is a process to check if it meets the verification requirements. Additionally,check for inconsistencies and complexity. In some cases complexity may be necessary, but validation should ensure that complexity is manageable.

This can be done with the help of review and rapid prototyping.

Step 4: Testbench architecture : Delivery

Is the test bench architecture diagram and document,sufficient to get the execution started? It is necessary but not sufficient unless you as a architect are fine with architecture deviating from its intent depending on team handling execution.

Ideal test bench architecture hand off from architect to execution team should be through a set of abstract classes. Abstract classes with the tasks, functions and key threads identified. Key user exposed APIs defined. Comments in header defining the functionality of class and functionality for tasks and functions to be written for guidance should be provided. Bonus points to architect for stitching these abstract classes and get it compiling before passing to execution team.

This is one of the best ways to pass intent without diluting. This allows restricting any poor implementation by the execution team to a class, function or task rather than letting it spread throughout like infectious disease all over the test bench code. This enables recovery from the damages of poor coding or lack of expertise of the execution team. It’s more work, but allows to preserve the cleanliness and intent.

There may be some practical limitations due to bandwidth availability of the architect. In this case the architect should first get these abstract classes implemented by the execution team and review them before the full blown execution kicks off.

Conclusion

A good testbench architecture balances between:

• Meeting the verification requirements
• Easing maintenance by staying close specification intent
• Execution friendly for team with the right level of cohesion and coupling