Testbench architecture – Functional division

One of the key to getting the functional division and reusability right in the testbench architecture is to think of it as product to be sold either as full solution or in parts. For example think of bus functional models(BFMs), Scoreboard, functional coverage should be individually licensable components. This thought process although virtual in many cases guides in the right direction.

Borrowing some concepts from software world, which is older and wiser. Key to good architecture is “cohesion and coupling”. Cohesion is related things staying together. Coupling is about the level of interdependency between the software modules. High cohesion leads to low coupling. Tight coupling leads to change in one module causing ripple effects of changes in other modules. Low coupling and high cohesion is desired.

Low cohesion and tight coupling leads to bad architecture. Bad architecture leads to unintended test bench bugs, harder debugs, maintenance pain and makes every update a challenge. All this leads to schedule slips and holes in verification.

Wear your verification goggle. This will help you to keep testbench light and focused on what is really needed.

Test bench architecture for functional division can be approached in two forms. Its best to look at it in both the views. Both have overlap but still capable of providing some unique insights.

• Structural point of view – Division of functionality into components
• Layered point of view  – Division into layers which group related components

Typically the bus functional models(BFM), scoreboards and  stimulus generation are few of the complex parts of the self checking constrained random testbenches. These should be carefully architected.