There are couple of additional challenges to be dealt while architecting the testbench. They are ambiguity in the requirements specification and some odd features not fitting with the mostly completed testbench architecture. Following sections provide some of the ideas as to how deal with them.

Handling ambiguity

One of the other challenges during architecture is handling ambiguity. The very nature of new products is they come bundled with certain level of ambiguity. Specifications themselves are evolving. It’s not practically possible to have clarity on everything during architecture phase. So its inevitable that architects have to devise ways to deal with the ambiguity.

The best way to cover the ambiguity is to first identify and document it. List the possible interpretations. Choose the interpretation which helps meet the end applications objective effectively. When it’s not possible to make any choices to handle ambiguity make its implementation in architecture programmable. This programmability will allow architecture flexibility for adapting to different possible resolutions on ambiguity at later stage of the project.

Quarantine inconsistency

There will always be some requirements that do not resonate with the natural structure of the test bench. When this happens first relook at architecture if new piece found was missing block of the puzzle. If its not and most the architecture is in-line of the specification intent and meeting most of the verification requirements then do not let this one requirement pollute the overall architecture. This is indication that this feature requires quarantining.

Keep it as separate as possible by defining clear boundaries with the existing architecture. These scenarios are very common in notorious error injection implementation.