Testbench architecture has three key dimensions to consider:

1. Space – Division of functionality
2. Time – Structuring the test simulation time
3. Concurrency – Handling interface and pipeline concurrency

Space

Space is about the functional division. Dividing functional space among different blocks of architecture. Concept of space is common even in software architecture. There are two ways to deal with coming up with optimal functional division. First is structural division and second is layered division. Both are two faces of the same coin.

Concept of the time and concurrency is unique to ASIC designs.

Concurrency

By nature hardware is parallel. In fact that’s very reason why applications go for ASIC usage and not do everything with the general-purpose processor. Dedicated hardware solutions bring in the performance that general-purpose software based processor system cannot match. This is possible due to concurrent nature of the hardware.

Concurrency of hardware manifests in both concurrent external interfaces and concurrent internal pipelines. Designs are organized as data path and control path. Both the data and control paths operate concurrently. There can be multiple concurrent data and control paths.

Concurrency in the context of test bench architecture refers to concurrency required in the test bench to fully exercise the concurrency in the design. Test bench should be fully capable of handling all the concurrent interfaces. It can be in the form of concurrent stimulus generation or concurrent response handling or concurrent functional coverage collection.

Concurrency in stimulus manifests as concurrent

• data stimulus generation,
• control stimulus generation along with
• concurrent asynchronous event generation

Time

Time refers to simulation time. HVLs like System Verilog have divided simulation time into various regions. Verification methodologies such as UVM have divided time into various phases. Both have different purpose to achieve.

Time in the context of test bench architecture is the structuring the test simulation from test beginning to end. This structuring is later mapped to the time phases supported by the verification methodologies. Typically test simulation time for architecture thought process is divided into three regions. Pre test, test run and post test.

“Pre test” is a phase preparing before the execution of the test starts. In pre test phase construction of test bench as per structural configuration, configuration of test bench components and initialization of the design under test are completed. This sets up the system in a state for the test to start. Initialization sequences are divided into initialization sequence to common to all tests and test specific initializations. Any initialization bypass hooks have to thought out and put in. Common initialization sequence is made part of the test bench. At the end of this phase DUT resets are released, clocks are running, registers are configured in the mode of test’s interest, test bench components have access to DUT interface and configured with respective configuration. All test bench components are waiting for the data and control command stimulus from the test.

“Test run” is a phase actual stimulus generation takes place. Test has to take care of doing any additional test specific initialization beyond the generic initialization done by the test bench common for all the tests. Concurrency required in the stimulus generation should be controllable by test activating different generators. Test should be able to achieve the synchronization with the test bench using test bench state, events or callbacks. At the end of “test run” phase all the required stimulus generation is completed to meet the test’s intent.

“Post test” is a phase where primarily the end of test implementation is done. End of test consists of waiting for end of stimulus and end of test checks. End of the test is also important piece of the test bench architecture. End of stimulus follows top down approach. End of stimulus waiting is implemented from outer layers to inner layer components of the layered test bench architecture. End of test check confirms various intended events have taken place and no unintended side effects have taken place.