Lect 16 – Architecting Testbenches

1. Lect 16 – Architecting Testbenches • Testbench considerations • Testbench creation • Reusable code • Hierarchy and hierarchy in code • Test harnesses • Configurable designs EE694v - Verification - Lect 16

2. 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 EE694v - Verification - Lect 16

3. 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. EE694v - Verification - Lect 16

4. 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. EE694v - Verification - Lect 16

5. 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). EE694v - Verification - Lect 16

6. 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. EE694v - Verification - Lect 16

7. 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 EE694v - Verification - Lect 16

8. 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. EE694v - Verification - Lect 16

9. 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 EE694v - Verification - Lect 16

10. 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 EE694v - Verification - Lect 16

11. 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. EE694v - Verification - Lect 16

12. Test Harnesses • Code for testharness may be the most leveraged verification code!! EE694v - Verification - Lect 16

13. 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. EE694v - Verification - Lect 16

14. 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. EE694v - Verification - Lect 16

15. 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. EE694v - Verification - Lect 16

16. 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 EE694v - Verification - Lect 16

17. 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 EE694v - Verification - Lect 16