TB Imp

VHDL Test Bench
Teemu Pitkänen
Teemu.pitkanen@tut.fi
TH318
(03) 3115 4778
TKT-1210 Digital design II, Lect5 1 Tampere University of Technology

© Teemu Pitkänen (teemu.pitkanen@tut.fi) Institute of Digital and Computer Systems
Introduction
◆ What is a VHDL test bench?
◆ Test bench structures
◆ Examples

What Is The VHDL Tes t B ench (TB )?
◆ VHDL test bench (TB) is a piece of VHDL code, which purpose is
to verify the functional correctness of HDL model.
◆ The main objectives of TB is to:
– Instantiate the design under test (DUT)
– Generate stimulus waveforms for DUT
– Generate reference outputs and compare them with the outputs of
DUT
– Automatically provide a pass or fail indication
◆ Test bench is a part of the circuits specification.
◆ Its a good idea to design the test bench before the DUT, why?

S timulus and R es pons e
◆ Three ways how TB can generate the stimulus:
– Generate them “on-the-fly”
– Read vectors stored as constants in an array
– Read vectors stored in a separate system file
◆ Response is produced in the test bench.
◆ Response can be stored into file for further processing.
◆ Example:
– Stimulus can be generated with Matlab and TB feeds it into DUT.
– DUT generates the response and TB stores it into file.
– Result can be compared to Matlab simulations.

Tes t B ench S tructures
◆ TB should be reusable without difficult modifications.
◆ The structure of the TB should be simple enough so that other
people understand its behaviour.
◆ Good test bench propagates all the generics and constants into
DUT.
◆ Question: How to verify that the function of the test bench is
correct?

S imple Tes t B ench
◆ Only the DUT is instantiated into test bench.
◆ Stimulus is generated inside the test bench
◆ Poor reusability.
◆ Suitable only for relatively simple designs.

A S imple Tes t B ench (2)
◆ DUT: Syncronous adder, entity, architecture, configuration
ENTITY tb_adder IS
PORT (
clk : IN STD_LOGIC;
a(2:0)
rst_n : IN STD_LOGIC;
a, b : IN UNSIGNED(2 DOWNTO 0); b(2:0)
y : OUT UNSIGNED(2 DOWNTO 0)); y(2:0)
END tb_adder; rst_n
ARCHITECTURE RTL OF tb_adder IS
BEGIN -- RTL clk
PROCESS (clk, rst_n)
BEGIN -- process
IF rst_n = ’0’ THEN -- asynchronous reset (active low)
y <= (OTHERS => ’0’);
ELSIF clk’EVENT AND clk = ’1’ THEN -- rising clock edge
y <= a + b;
END IF;
END PROCESS;
END RTL;
CONFIGURATION cfg_tb_adder OF tb_adder IS
FOR RTL
END FOR;
END cfg_tb_adder;
◆ Test bench
– Entity:
ENTITY simple_tb IS
END simple_tb;
– Architecture:
ARCHITECTURE stimulus OF simple_tb IS
– DUT:
COMPONENT tb_adder
PORT (
clk : IN STD_LOGIC;
a, b : IN UNSIGNED(2 DOWNTO 0);
y : OUT UNSIGNED(2 DOWNTO 0));
END COMPONENT;

– Clock period and connection signals:
CONSTANT period : TIME := 50 ns;
SIGNAL clk : STD_LOGIC := ’0’;
SIGNAL rst_n : STD_LOGIC;
SIGNAL a, b, y : unsigned(2 downto 0);
– Begin of the architecture and component instantiation:
DUT : tb_adder
PORT MAP (
clk => clk,
rst_n => rst_n,
a => a,
b => b,
y => y);
– Clock generation:
generate_clock : PROCESS (clk)
BEGIN -- process
clk <= NOT clk AFTER period/2;
END PROCESS;
– Stimuli generation and the end of the architecture:
rst_n <= ’0’,
’1’ AFTER 10 ns;
a <= "000",
"001" AFTER 225 ns,
"010" AFTER 375 ns;
b <= "000",
"011" AFTER 225 ns,
“010" AFTER 375 ns;
end stimulus; -- ARCHITECTURE
– Configuration:
CONFIGURATION cfg_simple_tb OF simple_tb IS
FOR stimulus
FOR DUT : tb_adder
USE ENTITY work.tb_adder(RTL);
END FOR;
END FOR;
END cfg_simple_tb;
◆ Simulation:

Tes t B ench with a S eparate S ource
◆ Source and DUT instantiated into TB.
◆ For designs with complex input and simple output.
◆ Source can be for instance an entity or a process.

A Tes t B ench with a S eparate S ource (2)
◆ Input stimuli for “adder” is generated in a separate entity
“counter”.

◆ Source, a clock-triggered upcounter
◆ Entity of the source:
ENTITY tb_counter IS
PORT (
clk : IN STD_LOGIC;
END tb_counter;

◆ Architecture of the source component:
ARCHITECTURE RTL OF tb_counter IS
BEGIN -- RTL
PROCESS (clk, rst_n)
VARIABLE count : UNSIGNED(2 DOWNTO 0);
BEGIN -- process
IF rst_n = ’0’ THEN -- asynchronous reset (active low)
y <= (OTHERS => ’0’);
count := (OYHERS => ’0’);
count := count + 1;
Y <= count;
END IF;
END PROCESS;
END RTL;

◆ Test bench:
– Architecture
ARCHITECTURE separate_source OF source_tb IS
– DUT and source
COMPONENT tb_adder
PORT (
clk : IN STD_LOGIC;
END COMPONENT;
COMPONENT tb_counter
PORT (
clk : IN STD_LOGIC;
END COMPONENT;

– Clock period and connection signals
SIGNAL response_out, stim_in : unsigned(2 downto 0);
– Port mappings of the DUT and the source
DUT : tb_adder
PORT MAP (
clk => clk,
rst_n => rst_n,
a => stim_in,
b => stim_in,
y => response_out);
i_source : tb_counter
PORT MAP (
clk => clk,
rst_n => rst_n,
y => stim_in);
– Clock and reset
BEGIN -- process
END PROCESS;
rst_n <= ’0’,
END separate_source
– Configuration
CONFIGURATION cfg_source_tb OF source_tb IS
FOR separate_source
FOR DUT : tb_adder
USE ENTITY work.tb_adder(RTL);
END FOR;
FOR i_source : tb_counter
USE ENTITY work.tb_counter(RTL);
END FOR;
END FOR;
TKT-1210 Digital designEND cfg_source_tb;
II, Lect5 18 Tampere University of Technology
◆ Simulation:

Tes t B ench with a S eparate S ource and
S ink
◆ Both the stimulus source and the sink are in separate instance.
◆ Complex source and sink without response-source interaction.

S mart Tes t B ench
◆ Circuit’s response affects further stimulus.

Tes t B ench with Text-IO
◆ Stimulus for DUT is read from an input file and the data is
modified in the source.
◆ The response modified in the sink is written in the output file.

A Tes t B ench with Text-IO (2)
◆ Test case:

◆ Test bench:
– Libraries, remember to declare the textio-library!
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_numeric.all;
use std.textio.all;
use IEEE.std_logic_textio.all;

– Architecture
ARCHITECTURE text_io OF source_tb IS
– DUT and the connection signals
COMPONENT tb_adder
PORT (
clk : IN STD_LOGIC;
END COMPONENT;

SIGNAL a, b, y : unsigned(2 downto 0);

– Port mapping
DUT : tb_adder
PORT MAP (
clk => clk,
rst_n => rst_n,
a => stim_in,
b => stim_in,
y => response_out);
– Clock and reset
BEGIN -- process
END PROCESS;
rst_n <= ’0’,
– Process
process (clk, rst_x)

– Declaration of the input and output files
FILE file_in : TEXT IS IN "datain.txt";
FILE file_out : TEXT IS OUT "dataout.txt";
– Variables for one line of the input and output files
VARIABLE line_in : LINE;
VARIABLE line_out : LINE;
– Variables for the value in one line
VARIABLE input_tmp : INTEGER;
VARIABLE output_tmp : INTEGER;

– Beginning of the process and reset
BEGIN -- process
IF rst_n = ’0’ THEN -- asynchronous reset
a <= (OTHERS => ’0’);
b <= (OTHERS => ’0’);
– Clock
– Read one line from the input file to the variable “line_in” and read
the value in the line “line_in” to the variable “input_mp”
IF NOT (ENDFILE(file_in)) THEN
READLINE(file_in, line_in);
READ(line_in, input_tmp);

– “input_tmp” is fed to the inputs of the DUT
– VAIHDA _VASTAAMAAN NUMERIC KIRJASTOA.
a <= CONV_UNSIGNED(input_tmp, 3);
b <= CONV_UNSIGNED(input_tmp, 3);
– The response of the DUT is converted to integer and fed to the
variable “output_tmp”
output_tmp := CONV_INTEGER(y);
– The variable “output_tmp” is written to the line “line_out” that is
written to the file “file_out”
WRITE(line_out, output_tmp);
WRITELINE(file_out, line_out);
– At the end of the input file the note “End of file!” is given
ELSE
ASSERT FALSE
REPORT "End of file!"
SEVERITY NOTE;
END IF;
◆ Input file provided ◆ Output file produced
to test bench by the test bench:

◆ Simulation:

G olden Des ig n
◆ DUT is compared to the specification i.e. the golden design.

The S imulation with A G olden Des ig n

S ame Tes t B ench for Different Des ig ns
◆ Architecture of the DUT can be changed using the
configuration.

S ame Tes t B ench for Different Des ig ns (2)
LIBRARY design_lib;
configuration cfg_test_bench OF test_bench IS
FOR schematic
-- configuration for post-synthesis simulation:
--FOR DUT : nand_omponent
--USE ENTITY design_lib.nand_component(SYN_schematic);
--END FOR;
-- configuration for functional simulation:
FOR DUT : nand_component
USE CONFIGURATION design_lib.cfg_nand_component;
END FOR;
END FOr;
END cfg_test_bench;
◆ DUT = instance name, nand_component = entity name,

SYN_schematic = architecture name, test_bench = entity of the
test bench, cfg_nand_component = configuration of the
nand_component, design_lib = library for the compiled designs.

Des ig n Flow

C omplex Tes t B ench
TB
DUT
Input Stimulus Results
Compare
File generation File
Golden
dynamic part design Pass/fail
of TB indication
static part of TB

Additional Information:
◆ VERA
– Integral part of Synopsys Smart Verification platform
– Test bench automation solution for module, block and full system
verification
– VERA test bench automation system is based on OpenVera
language
• High-level, object-oriented programming language developed
specifically to meet the requirements of functional verification.


TB Imp

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

TB Imp

Hochgeladen von

Copyright:

Verfügbare Formate

VHDL Test Bench

TKT-1210 Digital design II, Lect5 1 Tampere University of Technology

TKT-1210 Digital design II, Lect5 2 Tampere University of Technology

TKT-1210 Digital design II, Lect5 3 Tampere University of Technology

TKT-1210 Digital design II, Lect5 4 Tampere University of Technology

TKT-1210 Digital design II, Lect5 5 Tampere University of Technology

TKT-1210 Digital design II, Lect5 6 Tampere University of Technology

TKT-1210 Digital design II, Lect5 8 Tampere University of Technology

TKT-1210 Digital design II, Lect5 11 Tampere University of Technology

TKT-1210 Digital design II, Lect5 12 Tampere University of Technology

TKT-1210 Digital design II, Lect5 13 Tampere University of Technology

TKT-1210 Digital design II, Lect5 14 Tampere University of Technology

TKT-1210 Digital design II, Lect5 15 Tampere University of Technology

TKT-1210 Digital design II, Lect5 16 Tampere University of Technology

TKT-1210 Digital design II, Lect5 19 Tampere University of Technology

TKT-1210 Digital design II, Lect5 20 Tampere University of Technology

TKT-1210 Digital design II, Lect5 21 Tampere University of Technology

TKT-1210 Digital design II, Lect5 22 Tampere University of Technology

TKT-1210 Digital design II, Lect5 23 Tampere University of Technology

TKT-1210 Digital design II, Lect5 24 Tampere University of Technology

CONSTANT period : TIME := 50 ns;

TKT-1210 Digital design II, Lect5 25 Tampere University of Technology

TKT-1210 Digital design II, Lect5 26 Tampere University of Technology

TKT-1210 Digital design II, Lect5 27 Tampere University of Technology

TKT-1210 Digital design II, Lect5 28 Tampere University of Technology

TKT-1210 Digital design II, Lect5 30 Tampere University of Technology

TKT-1210 Digital design II, Lect5 31 Tampere University of Technology

TKT-1210 Digital design II, Lect5 32 Tampere University of Technology

TKT-1210 Digital design II, Lect5 33 Tampere University of Technology

TKT-1210 Digital design II, Lect5 34 Tampere University of Technology

◆ DUT = instance name, nand_component = entity name,

TKT-1210 Digital design II, Lect5 35 Tampere University of Technology

TKT-1210 Digital design II, Lect5 36 Tampere University of Technology

TKT-1210 Digital design II, Lect5 37 Tampere University of Technology

TKT-1210 Digital design II, Lect5 38 Tampere University of Technology

Das könnte Ihnen auch gefallen