Lect 12,13,14 – 762 Testbenches • Lets look at the EE 762 testbenches • Look at stimulus generation techniques • Look at response.

Download Report

Transcript Lect 12,13,14 – 762 Testbenches • Lets look at the EE 762 testbenches • Look at stimulus generation techniques • Look at response.

Lect 12,13,14 – 762 Testbenches
• Lets look at the EE 762 testbenches
• Look at stimulus generation techniques
• Look at response monitoring techniques
EE694v - Verification - Lect 12
-1-
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
• 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
EE694v - Verification - Lect 12
-2-
The waveform
EE694v - Verification - Lect 12
-3-
Pr_step2 Testbench
The ALU Slice
• Exhaustive testing is no longer a possibility.
Number of inputs has grown to 15. Would need
32,768 inputs, some of which wouldn’t 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
EE694v - Verification - Lect 12
-4-
Pr_step3 – 8 Bit ALU
Automatic 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.
EE694v - Verification - Lect 12
-5-
Pr_step4 – Behavioral
ALU 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
EE694v - Verification - Lect 12
-6-
Pr_step7 – Using Busses
The 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 highimpedance (z) to the value, the value is held on the
bus and then the bus returns to a value of z.
EE694v - Verification - Lect 12
-7-
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
EE694v - Verification - Lect 12
-8-
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.
EE694v - Verification - Lect 12
-9-
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.
EE694v - Verification - Lect 12
-10-