lect 16 – architecting testbenches

EE694v - Verification - Lect 16 -1-

Lect 16 – Architecting Testbenches

• Testbench considerations• Testbench creation• Reusable code• Hierarchy and hierarchy in code• Test harnesses• Configurable designs


Testbench Creation

• A testplan for any realistic design will necessitate multiple testbenches

• Each testbench will implement a set of testcases• Need to have a structure for stimulus generation

and response monitoring that– Minimizes testbench maintenance

– Eases creation of testbenches

– Promotes reusability of verification code components


Reusable Verification Components

• Goal is to maximize to verification code that is reusable.

• Reusable code maps across the testbenches for multiple devices under verification and minimizes the testbench development effort.

• Testbench code can be divided into– Reusable test harness– Testcase specific code

• Examples – code for the PCI bus, ISA bus, etc.


Reusable Code (cont)

• Inputs and outputs to/from a design is done using global signals

• Can use the same procedures/code to assign-to and monitor responses across all the testbenches for a design

‘Testcase’ is where the inputs change and the value of the expected response is kept.


Testbenches

• A testcase and a harness form a testbench

• “Testcase” in the figure is the code of the testbench that allows application of the test vectors

• “Harness” is the code that simplifies application of testcases to a design and simplifies monitoring of the response(s).


Hierarchy

• As low level features are verified and/or you wish to simplify the application of testcases, it often better to write procedures.

• A procedural interface allows access to features or functions of the design through procedures.


Hierarchy in Code

• Rather than one huge process, code of testbench should be structured.

• May have multiple layers of procedural interfaces– Low level layers provide detailed control

– High level layers provide abstraction and hiding of low level details

– Allows for correction of the low level without affecting the high levels or the test cases


Hierarchy in Code (2)

• DO NOT ATTEMPT TO IMPLEMENT ALL FUNCTIONALITY IN A SINGLE LEVEL for any design of significant size.

• Using procedural interfaces means– Testcases do not need to know low-level detail of the design.

– Testcases do not need to know low-level details of the physical interfaces.

– Physical implementation can be modified without changes to the testcases, i.e., changing from one bus protocol to another.


Testbench Implementation

• Testbench writing should start with the basic functionality of the design

• High-level functions are added incrementally• DO NOT WRITE THE COMPLETE

TESTBENCH AND THEN TEST!!• An incremental approach minimizes development

effort and– Does not result in code that is not needed– Debugging is now scoped to the new code


VHDL Verification

• One goal is to be able to reuse verification code– Within the same project– Across multiple projects– Cannot be achieved if only a single level of hierarchy.

• Replication is not reuse!!– Physically copying code from one testbench to another

just means you have another copy of code to maintain.– Only reuse should be a call to code with different

parameters. Now only one copy of code to maintain.

• Reusable VHDL code should be placed in packages


Using Procedures

• Arguments to procedures can be signals or variables.

• If a signal value is passed to a procedure must be sure that the correct value is passed. If you have a signal assignment immediately before the call to the procedure, signal will still have its old value!!

• Must take care in procedure call interfacing or all you may need to change several procedures when even one changes.


Test Harnesses

• Code for testharness may be the most leveraged verification code!!


Test Harness (2)

• Common elements in all testbenches:– Declaration of the component

– Declaration of the interface signals

– Instantiation of the design under verification

– Mapping of interface signals to the ports

– Mapping of interface signals to the signal-class arguments of bus-functional procedures

• (b) shows how testbench can be restructured to allow reuse.


Multiple Identical Interfaces

• Designs can often have multiple instances of the same interface– EX: Packet switching design may have multiple packet

input and output ports.

• All interfaces have the same control signals• Often very helpful to put signals into an array to

identify which port/interface is being referenced.


More on Text I/O

• Each testcase provides different stimulus to which the expected response is different.

• Often helpful to put inputs/expected responses in a file and read them using text I/O

• Filename can be hardcoded or changeable

• Hardcoding output file names can cause difficulties if more than 1 simulation run at a time.


Configurable Designs

• Soft configurability– Done through a programmable interface and can be

changed at run time

– Usually verified by changing the parameters in a testcase.

EX: - offsets for the almost-full and almost-empty flags on a FIFO

- the baud rate of an UART

- routing table in a packet router


Configurable Designs (2)

• Hard configurability– Fundamental to the design– Cannot be modified at runtime

– Constant for the duration of the simulation

• Configuration of models can be done using generics– Generic values can be propagated down the hierarchy

of the design

EX: - PCI bus that runs at 33, 66, or 100 MHz - width and depth of a FIFO

lect 16 – architecting testbenches

Documents