Lect 12,13,14

1
Lect 12,13,14 762 Testbenches

• Lets look at the EE 762 testbenches
• Look at stimulus generation techniques
• Look at response monitoring techniques

2
Pr_step1 Testbench 4 to 1 Mux

• Number of inputs to design is small only 6
  inputs input vector space is 26 64
• Exhaustive testing used as only 64 testcases
• Output is checked via visual inspection of the
  waveform
• Total effort effort for automation of check
• Design under verification is considered a black
  box must verify from the inputs and monitor
  only the outputs
• NOTE Still use additional indications/labels in
  testbench to make visual verification easier

3
The waveform
4
Pr_step2 TestbenchThe ALU Slice

• Exhaustive testing is no longer a possibility.
  Number of inputs has grown to 15. Would need
  32,768 inputs, some of which wouldnt make sense.
• Choose 22 operations that the ALU slice is
  capable of computing and verify them for 4
  inputs. 2 operations are verified for 8 inputs.
  Total - 96
• Results are still checked visually
• Still effort for automated checking

5
Pr_step 8 Bit ALUAutomatic Checking of Results

• Once you get to an 8 bit result can no longer do
  a visual verification of results.
• Number of inputs has grown to 29. Exhaustive
  testing would take 539 million inputs!!!
• Number of input applied for testing is now 168
• A separate process now monitors the outputs
• Expected outputs are listed in an array in the
  testbench. Note the task to maintain this style
  of output checking. Not practical for more
  design efforts.

6
Pr_step BehavioralALU Description

• Using behavioral VHDL code to do description of
  the ALU
• Array of expected outputs now contain comments as
  to which test it represents
• Operation being tested and test number used to
  get expected result out of table Test can be
  easily sequenced in a different order.
• Pr_step5 testbench structure is the same
  advancement to use of procedures in processes
• Pr_step6 testbench structure is the same
  advancement to the use of packages

7
Pr_step Using BussesThe Datapath Register Set

• This step advances to the use of busses for the
  transfer of data.
• There are now multiple drivers for the bus
  signals
• Procedure in testbench both applies values and
  checks results
• Bus is checked when it transitions from
  high-impedance (z) to the value, the value is
  held on the bus and then the bus returns to a
  value of z.
• Bus requires continual monitoring.

8
Pr_step8 The Complete Datapath

• Need a testing plan as to what needs tested and
  how it will be tested.
• Initialize control signals (14 signals)
• Load initial values into registers and make sure
  they were loaded correctly, i.e., dump registers.
  Also assures that busses are working at least in
  part.
• Do basic operations using ALU(17 operations).
  Only the connectivity of the ALU needs verified
  not its full functionality.
• Final dump of registers

9
Pr_step8 (cont)

• Procedures written to call bus cycle procedure
  for both one and two register operand operations
• Another procedure is used to run the bus cycle
  and do the results checking.
• Registers and functional aspects of ALU are
  assumed to be working for this testbench.
  Correct integration is checked for.
• Review the code.

10
Formatting Listing and Waveform

• A .do file is generated that provides a
  uniformity to the generation of the listing file
  and also to the waveform.
• A good idea is to develop such practices in your
  work, i.e., a format that makes it easier for you
  to locate that an error was found should be
  adopted.

11
Testing a sequential machine

• Free running clock of a given duty cycle
• May need to be checked in an industrial setting.
• Mixed mode system
• Discrete modeling of analog components

12
Floating point tests

• Testing of Floating point execution unit.
• Hugh test space. Very large number of tests.
• Easiest
• A file of test inputs and expected results
• Each test is a transaction
• DUT responds to transaction
• Have reviewed textio