Lect 16

1
Lect 16 Architecting Testbenches

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

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

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.

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.
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).

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.

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

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.

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

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

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.

12
Test Harnesses

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

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.

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.

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.

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
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