Lect 16 – Architecting
Testbenches
•
•
•
•
•
•
Testbench considerations
Testbench creation
Reusable code
Hierarchy and hierarchy in code
Test harnesses
Configurable designs
EE694v - Verification - Lect 16
-1-
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
-2-
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
-3-
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
-4-
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
-5-
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
-6-
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
-7-
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
-8-
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
-9-
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
-10-
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
-11-
Test Harnesses
• Code for
testharness may be
the most leveraged
verification code!!
EE694v - Verification - Lect 16
-12-
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
-13-
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
-14-
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
-15-
Configurable Designs
• Soft configurability
– Done through a programmable interface and can be
changed at run time
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
– Usually verified by changing the parameters in a
testcase.
EE694v - Verification - Lect 16
-16-
Configurable Designs (2)
• Hard configurability
– Fundamental to the design
– Cannot be modified at runtime
EX: - PCI bus that runs at 33, 66, or 100 MHz
- width and depth of a FIFO
– 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
EE694v - Verification - Lect 16
-17-