￡ⅫNX° Writing Efficient Testbenches reg reset / declaration of signals wire [4: 0] shiftregi reg [4:01 datai reg [1: 0] sel // instantiation of the shift reg design below shift reg dut( clock (clock) load (load) reset (reset) shiftreg (shiftreg e1(se1)) //this process block sets up the free running clock tial b lock =0 #50 clock clock end initial begin// this process block specifies the stimulus reset = 1i dat 5′b00000 load se1=2′b00; #200 data=5′b00001 oad = 0: #200 2′b10 #1000 ssto d initial begin// this process block pipes the ASCII results to the Stimeformat(-9, l,ns",12)i Sdisplay (" Time clk Rst Ld SftRg Data Sel")i Monitor("暑t悬b各b暑b暑b暑b各b",Srea1time clock, reset, load, shiftreg, data, sel) dimodule The testbench, above, instantiates the design, sets up the clock, then provides the stimuli. All process blocks start at simulation time zero and are concurrent. The pound sign(#) specifies the delay before the next stimulus is applied. The Sstop command instructs the simulator to stop testbench simulation(all testbenches should contain a stop command). Finally, the Smonitor statement echoes the results in ASCll format to the screen or a piped text editor. Following is a VHDL testbench that instantiates and provides stimulus to the verilog shift VHDL Example: library IEEe entity testbench is end entity testbench architecture test reg of testbench is t re www.xilinx.com XAPP199(v1.0)June11,2001 1-800-255-7778
6 www.xilinx.com XAPP199 (v1.0) June 11, 2001 1-800-255-7778 Writing Efficient Testbenches R reg reset; // declaration of signals wire [4:0] shiftreg; reg [4:0] data; reg [1:0] sel; // instantiation of the shift_reg design below shift_reg dut(.clock (clock), .load (load), .reset (reset), .shiftreg (shiftreg), .data (data), .sel (sel)); //this process block sets up the free running clock initial begin clock = 0; forever #50 clock = ~clock; end initial begin// this process block specifies the stimulus. reset = 1; data = 5’b00000; load = 0; sel = 2’b00; #200 reset = 0; load = 1; #200 data = 5’b00001; #100 sel = 2’b01; load = 0; #200 sel = 2’b10; #1000 $stop; end initial begin// this process block pipes the ASCII results to the //terminal or text editor $timeformat(-9,1,"ns",12); $display(" Time Clk Rst Ld SftRg Data Sel"); $monitor("%t %b %b %b %b %b %b", $realtime, clock, reset, load, shiftreg, data, sel); end endmodule The testbench, above, instantiates the design, sets up the clock, then provides the stimuli. All process blocks start at simulation time zero and are concurrent. The pound sign (#) specifies the delay before the next stimulus is applied. The $stop command instructs the simulator to stop testbench simulation (all testbenches should contain a stop command). Finally, the $monitor statement echoes the results in ASCII format to the screen or a piped text editor. Following is a VHDL testbench that instantiates and provides stimulus to the Verilog shift register design above. VHDL Example: library IEEE; use IEEE.std_logic_1164.all; entity testbench is end entity testbench; architecture test_reg of testbench is component shift_reg is
Writing Efficient Testbenches ￡ⅫL|NX port (clock in std logici reset in st d: in std logici sel in std logic vector (1 downto 0) d logic hiftreg out std logic vector(4 downto 0)) nd componenti signal clock, reset, load: std logic signal shiftreg, data: std logic vector(4 downto 0) constant ClockPeriod: TIME 50 ns n UUT shift reg port map (clock = clock, reset = reset, load = load, data = dat shiftreg = shiftreg)i process begin clock < not clock after (clockPeriod / 2) end process process begin data<="00000 it for 200 nsi reset<=!0′ data<="00001 wait for 100 nsi se1<="01 1oad<=!0′ 1<="10"; it for 1000 hitecture test r The VHDL testbench above is similar in functionality to the Verilog testbench shown previously, with the exception of a command to echo the output to the terminal In VHDL, the std textio package is used to display information to the terminal, and this will be covered in the next section Automatic g the verification of testbench results is recommended, particularly for large Verification utomation reduces the time required to check a design for correctness, and human error Several methods are commonly used to automate testbench verification Database Comparisons. First, a database file containing expected output(a"golden vector" file)is created. Then, simulation outputs are captured and compared to the reference vectors in the golden vector file( the unix diff utility can be used to compare the ASCll database files). However, since pointers from output to input files are not provided, a disadvantage of this method is the difficulty of tracing an incorrect output to the source of the error 2. Waveform Comparison Waveform comparisons can be performed automatically or manually. The automatic method employs a testbench comparator to compare a golden waveform against the testbench output waveform. The Xilinx HDL Bencher tool can be XAPP199(v10)June11,2001 www.xilinx.com 1-800-255-7778
Writing Efficient Testbenches XAPP199 (v1.0) June 11, 2001 www.xilinx.com 7 1-800-255-7778 R port (clock : in std_logic; reset : in std_logic; load : in std_logic; sel : in std_logic_vector(1 downto 0); data : in std_logic_vector(4 downto 0); shiftreg : out std_logic_vector(4 downto 0)); end component; signal clock, reset, load: std_logic; signal shiftreg, data: std_logic_vector(4 downto 0); signal sel: std_logic_vector(1 downto 0); constant ClockPeriod : TIME := 50 ns; begin UUT : shift_reg port map (clock => clock, reset => reset, load => load, data => data, shiftreg => shiftreg); process begin clock <= not clock after (ClockPeriod / 2); end process; process begin reset <= ’1’; data <= "00000"; load <= ’0’; set <= "00"; wait for 200 ns; reset <= ’0’; load <= ’1’; wait for 200 ns; data <= "00001"; wait for 100 ns; sel <= "01"; load <= ’0’; wait for 200 ns; sel <= "10"; wait for 1000 ns; end process; end architecture test_reg; The VHDL testbench above is similar in functionality to the Verilog testbench shown previously, with the exception of a command to echo the output to the terminal. In VHDL, the std_textio package is used to display information to the terminal, and this will be covered in the next section. Automatic Verification Automating the verification of testbench results is recommended, particularly for larger designs. Automation reduces the time required to check a design for correctness, and minimizes human error. Several methods are commonly used to automate testbench verification: 1. Database Comparisons. First, a database file containing expected output (a “golden vector” file) is created. Then, simulation outputs are captured and compared to the reference vectors in the golden vector file (the unix diff utility can be used to compare the ASCII database files). However, since pointers from output to input files are not provided, a disadvantage of this method is the difficulty of tracing an incorrect output to the source of the error. 2. Waveform Comparison. Waveform comparisons can be performed automatically or manually. The automatic method employs a testbench comparator to compare a golden waveform against the testbench output waveform. The Xilinx HDL Bencher tool can be
￡Ⅻ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-7778
8 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 runtime intervals to provide automatic error checking. This technique works fine in small to midsize 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;