100 likes | 115 Views
Explore testbenches for EE694v, including stimulus generation techniques and response monitoring techniques. Lectures cover various topics such as testing a 4-to-1 Mux, verifying operations of an ALU Slice, automatic checking of results, using behavioral VHDL code, and testing a complete datapath.
E N D
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
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
The waveform EE694v - Verification - Lect 12
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 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
Pr_step3 – 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. EE694v - Verification - Lect 12
Pr_step4 – 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 EE694v - Verification - Lect 12
Pr_step7 – 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. EE694v - Verification - Lect 12
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
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
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