Test Benches

TEST BENCHES

• A testbench is used to verify the specified functionality of a design. It provides the stimuli for the Device Under Test (DUT) and analyses the DUT's respones or stores them in a file. • Information necessary for generating the stimuli can be integrated directly in the testbench or can be loaded from an external file. • Simulation tools visualize signals by means of a waveform which the designer compares with the expected response.

• In case the waveform does not match the expected response, the designer has to correct the source code. When dealing with bigger designs, this way of verification proofs impractical and will likely become a source of errors. The only way out would be a widely automated verification

• • • • • • • •

Stimuli transmitter to DUT (test vectors) Need not be synthesizable No ports to the outside Environment for DUT Verification and validation of the design Several output methods Several input methods

Structure of a VHDL Testbench entity TB_TEST is

-----Empty entity

end TB_TEST; architecture BEH of TB_TEST is -- component declaration of the DUT -- internal signal definition begin -- component instantiation of the DUT -- clock generation -- stimuli generation end BEH;

configuration CFG_TB_TEST of TB_TEST is for BEH; -- customized configuration end for; end CFG_TB_TEST;

Example • •

entity TB_TEST is end TB_TEST;

• • • • • • • •

architecture BEH of TB_TEST is component TEST port(CLK : in std_logic; RESET : in std_logic; A : in integer range 0 to 15; B : in std_logic; C : out integer range 0 to 15); end component;

• •

constant PERIOD : time := 10 ns;

• signal W_CLK : std_logic := '0'; • signal W_A, W_C : integer range 0 to 15; • signal W_B : std_logic; • signal W_RESET : std_logic; • begin • DUT : TEST • port map(CLK => W_CLK, • RESET => W_RESET, • A => W_A, • B => W_B, • C => W_C); • ···

-- Initial clock signal value set to '0' • The example shows a VHDL testbench for the design TEST. The design is declared as component in the declaration part of the architecture BEH. A constant PERIOD is defined to set the clock period. Internal signals that are needed as connections to the DUT are also declared. It is important to initialize the clock signal either to '0' or '1' instead of its default value 'u' because of the clock generation construct that is used later on.

Clock and Reset Generation W_CLK <= not W_CLK after PERIOD/2; -- complex version W_CLK <= '0' after PERIOD/4 when W_CLK='1' else '1' after 3*PERIOD/4 when W_CLK='0' else '0';

comments • Simple signal assignment • endless loop • W_CLK must be initialized to '0' or '1' (not 'u' = 'u') • symmetric clock, only • Conditional signal assignment • Complex clocking schemes • Realization as process introduces huge overhead

W_RESET <= '0', '1' after 20 ns, '0' after 40 ns; -------------Reset generation assert now>100*PERIOD report "End of simulation" severity failure; --------------Simulation termination via assert

• The clock stimulus is the most important one for synchronous designs. It can be created either with a concurrent signal assignment or within a clock generation process. As a process requires a lot of "overhead" when compared to the implemented functionality, the concurrent version is recommended.

• In the most simple form shown on top, the clock runs forever and is symmetric. As the signal value is inverted after half of the clock period, the initial signal value must not be 'u', i.e. its start value has to be explicitly declared. The more elaborated example below shows the generation of an asymmetric clock with 25% duty cycle via conditional signal assignments. Please note that the default signal value needs not to be specified because of the unconditional else path that is required by the conditional signal assignment.

• The complete simulation is stopped after 100 clock cycles via the ASSERT statement. Of course, the time check can be included in a conditional signal assignment as well.

• Clocks with a fixed phase relationship are modeled best with the ' delayed ' attribute similar to the following VHDL statement: "CLK_DELAYED <= W_CLK'delayed(5 ns);" • The reset realization is straight forward: It is initialized with '0' at the beginning of the simulation, activated, i.e. set to '1', after 20 ns and returns to '0' (inactive) after an additional 20 ns for the remainder of the simulation.

Stimuli Generation ··· STIMULI : process begin W_A <= 10; W_B <= '0'; wait for 5*PERIOD; W_B <= '1'; wait for PERIOD; ··· wait; end process STIMULI; ···

All other DUT inputs can be stimulated the same way. Yet, the pattern generation via processes is usually preferred because of its sequential nature. Please note that a wait statement is required to suspend a process as otherwise it would restart. More complex testbenches will show dynamic behaviour, i.e. the input stimuli will react upon DUT behaviour. This may lead eventually to a complete behavioural model of the DUT environment.

Response Analysis ·· process(W_C) begin assert W_C > 5 --message, if false report "WRONG RESULT!!" severity ERROR; end process; ··· --Assertion with severity level --Note --Warning --Error (default) --Failure· · ·

• ··· • process(W_C) • begin • assert W_C > 5 • report "WRONG RESULT in " & • W_C'path_name & • "Value: " & • integer'image(W_C) • severity error; • ··· ----Additional attributes in VHDL'93 ---'path_name ---'inst_name --'image

• WRONG RESULT in TB_TEST:W_C Value: 2 ---Report in simulator In VHDL ’93 there are • Additional attributes for debugging purposes • Report without assert statement

• The ' assert ' statement is suited best for performing automatic response analysis. An assertion checks a condition and will report a message, if the condition is false. Depending on the chosen severity level and the settings in the simulation tool, the simulation either resumes (e.g. note, warning) or stops (e.g. error, failure) after reporting that the assertion fails. The default severity level is ' error '.

• The message that is reported is defined by the the designer. In order to achieve dynamic reports that offer more detailed debugging information in case of errors several new attributes were defined in VHDL'93. They provide additional information about the circumstances that lead to the failing assertion: ' instance_name ' and ' path_name ' may be used to locate the erronous module. The path information is necessary when one component is instantiated at various places within a complex design. The ' image ' attribute looks like a function call. Its argument is returned as string representation and the data type is the prefix of the attribute.

• As a report is generated whenever the assertion condition evaluates to ' false ', it can be forced by setting this condition to the fixed value ' false '. This construction is no longer necessary in VHDL'93, i.e. the 'report' keyword may be used without a preceding assertion.

• The entity of a testbench is completely empty, because all necessary stimuli are created standalone. Otherwise a testbench for the testbench would be needed. As the DUT's inputs cannot be stimulated directly, internal temporary signals have to be defined. In order to distinguish between port names and internal signals, prefixes can be employed, for instance "W_" to indicate a wire.

• The declaration part of the testbench's architecture consists of the definition of the internal signals, a component declaration of the DUT or DUTs and perhaps some constant definitions e.g to set the clock period duration.

• A stimuli process provides the values for the DUT's input ports, in which behavioural modelling can be employed as there is no need to synthesize it. Sometimes, models of external components are available (probably behavioural description, only) and can be used similar to create a whole system. • A configuration is used to pick the desired components for the simulation.