Exploring a generic testbench architecture

The primary objective of a generic testbench is to provide a quick configurable setup for basic verification of any design. Such a generic testbench shall be configurable enough to support different kinds of system designs, supporting different features, thus enabling reuse of the same testbench across similar designs.

Scalability of the testbench becomes a challenge when complexity of the design grows and a large number of interfaces need to be supported by the design. The conventional approach of having a testbench interconnect doesn't meet the need of a scalable generic testbench due to obvious limitations of the pre-configured interconnects. Also, usage of a huge testbench interconnect makes the testbench overly complex which in turn can make the verification process cumbersome.

So, there is a growing need of a methodology or an architecture which will help in the generation of a simpler scalable testbench that can support varying sub-system design features. This architecture will also be flexible enough to allow users to configure and define the interfaces and connect them according to the design/verification requirements.

This paper discusses both the conventional testbench architecture and the new methodology to a scalable generic testbench architecture. A processor sub-system is taken as the design example for discussion.

Typical sub-system design under verification

Figure 1 details the different components of a typical processor sub-system design. A sub-system can have multiple processors (each can be multi-core), other masters e.g., DMA, system interconnect layer consisting of multiple interconnects as per complexity, memories and memory controllers, peripherals (like I2C, SPI, SSP, SMBUS, GPIO, controllers, etc. as per requirement) and debug logic to facilitate on-chip debug process. The system interconnect supports multiple master and slave interfaces, supporting different protocols with varying bus widths. The peripheral layer gives out multiple interfaces supporting different protocols. The debug logic also has its own control and trace interfaces. Apart from all these, there will be additional set of control and status signals to/from the design, memory power mode signals, design power island signals and clocks, resets and interrupts. So, in general, we can categorise the type of interfaces supported by any typical large sub-system design into following:

a) Master interfaces of varying bus-widths, supporting different protocols
b) Slave interfaces of varying bus-widths, supporting different protocols
c) Peripheral specific bus interfaces
d) Debug control and trace interface
e) General purpose control and status signals
f) Power mode signals
g) Clocks, resets and interrupts

In order to verify the sub-system completely, the primary goal will be to exercise all these interfaces as per the specified functionalities. And to enable that process, the testbench built around the design should have components hooked up to all these interfaces and provide necessary control to the testbench components to exercise the interfaces thoroughly.

Conventional testbench architecture

Figure 2 shows a very simple conventional testbench architecture, where each of the design interfaces are hooked up with suitable testbench components. The testbench interconnect handles traffic from/to master/slave interfaces and redirects the transfer to the appropriate testbench slave components. Different types of testbench components are connected to the testbench interconnect based on the design needs. Some of the variants are:

a) SLV n—memories or response slaves or VIPs are connected to the slave interfaces
b) MSTR n—master modules/drivers or VIPs hooked up to master interfaces
c) DBG/TRACE CTRL—debug control and trace compare module catering to the debug/trace interface
d) CTRLR (PWR/ CLK)—different controller/generators used to drive the interrupts, clocks, resets, power mode signals, and
e) TB_REG—testbench registers to control the general purpose I/Os
f) TUBE—processors require a means of communication to the testbench to notify when they have completed running the code. Tube is that module which facilitates that process. Processors write specific instructions that can be displayed on the console and can terminate the simulation when required or they can write specific values indicating present status of the processors.