￡ⅫNX° Writing Efficient Testbenches used to perform automatic waveform comparisons(for HDL Bencher information, go to http://www.xilinx.com/products/software/statecad/index.htm 3. Self-Checking Testbenches. A self-checking testbench checks expected results against actual results at run time not at the end of simulation. since useful error-tracking nformation can be built into the testbench to show where a design fails, debugging time is significantly shortened. Further information on self-checking testbenches is provided in the next section Self-Checking Self-checking testbenches are implemented by placing a series of expected vectors in a Testbenches testbench file. These vectors are compared at defined run-time intervals to actual simulation results If actual results match expected results, the simulation succeeds. If results do not match expectations, the testbench reports the discrepancies Implementing self-checking testbenches is simpler for synchronous designs since expected and actual results can be compared at a clock edge or after every "n"clock cycles. Comparison methods also depend on the nature of the design. For example, a testbench for memory w/O should check results each time new data is written to or read from a memory location. Similarly, if a design uses a significant number of combinatorial blocks, combinatorial delays must be taken into account when expected results are specified In a self-checking testbench, expected outputs are compared to actual outputs at regular run time intervals to provide automatic error checking. This technique works fine in small to mid size designs. However, since possible output combinations increase exponentially with design complexity, writing a self-checking testbench for a large design is much more difficult and time Below are examples of simple, self-checking testbenches written in Verilog and VHDL: Verilog Example Following the instantiation of the design, expected results are specified. Later in the code, expected and actual results are compared, and the results are echoed to the terminal. If there are no mismatches, an"end of good simulation" message is displayed. If a mismatch occurs, an error is reported along with the mismatched expected and actual values timescale 1 ns 1 ps module test reg threset, tbstrtstop ire [6:01 onesout, tensout parameter cycles =25 reg [9: 0] Data in t [0: cycles]i /////y Instantiation of the Design ///////1 stopwatch UUT ( ClK (bclk),. RESET (tbreset),. sTRTSToP (tbstrtstop) ONESOUT (onesout),. TENSOUT (tensout),. TENTHSOUT(tbtenthsout)) e[4: 0 tbonesout, tbtensout assign thtensout led2hex(tensout ssign tbonesout led2hex(onesout) ///1 EXPECTED RESULTS /////1yyy initial begin Data in t[1]=10′b1111111110; ata in t[2]=10′b1111111101 Data_int[3]=10′b111111011 t[4]=10′b1111110 www.xilinx.com XAPP199(v1.0)June11,2001 1-800-255-77788 www.xilinx.com XAPP199 (v1.0) June 11, 2001 1-800-255-7778 Writing Efficient Testbenches R used to perform automatic waveform comparisons (for HDL Bencher information, go to: http://www.xilinx.com/products/software/statecad/index.htm) 3. Self-Checking Testbenches. A self-checking testbench checks expected results against actual results at run time, not at the end of simulation. Since useful error-tracking information can be built into the testbench to show where a design fails, debugging time is significantly shortened. Further information on self-checking testbenches is provided in the next section Self-Checking Testbenches Self-checking testbenches are implemented by placing a series of expected vectors in a testbench file. These vectors are compared at defined run-time intervals to actual simulation results. If actual results match expected results, the simulation succeeds. If results do not match expectations, the testbench reports the discrepancies. Implementing self-checking testbenches is simpler for synchronous designs since expected and actual results can be compared at a clock edge or after every “n” clock cycles. Comparison methods also depend on the nature of the design. For example, a testbench for memory I/O should check results each time new data is written to or read from a memory location. Similarly, if a design uses a significant number of combinatorial blocks, combinatorial delays must be taken into account when expected results are specified. In a self-checking testbench, expected outputs are compared to actual outputs at regular run￾time intervals to provide automatic error checking. This technique works fine in small to mid￾size designs. However, since possible output combinations increase exponentially with design complexity, writing a self-checking testbench for a large design is much more difficult and time consuming. Below are examples of simple, self-checking testbenches written in Verilog and VHDL: Verilog Example Following the instantiation of the design, expected results are specified. Later in the code, expected and actual results are compared, and the results are echoed to the terminal. If there are no mismatches, an “end of good simulation” message is displayed. If a mismatch occurs, an error is reported along with the mismatched expected and actual values. ‘timescale 1 ns / 1 ps module test_sc; reg tbreset, tbstrtstop; reg tbclk; wire [6:0] onesout, tensout; wire [9:0] tbtenthsout; parameter cycles = 25; reg [9:0] Data_in_t [0:cycles]; // ///////////////////////////// // Instantiation of the Design // ///////////////////////////// stopwatch UUT (.CLK (tbclk), .RESET (tbreset), .STRTSTOP (tbstrtstop), .ONESOUT (onesout), .TENSOUT (tensout), .TENTHSOUT (tbtenthsout)); wire [4:0] tbonesout, tbtensout; assign tbtensout = led2hex(tensout); assign tbonesout = led2hex(onesout); /////////////////////////////////////////////////////////////// //EXPECTED RESULTS /////////////////////////////////////////////////////////////// initial begin Data_in_t[1] =10’b1111111110; Data_in_t[2] =10’b1111111101; Data_in_t[3] =10’b1111111011; Data_in_t[4] =10’b1111110111;