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.