VHDL – Test benches

How to simulate VHDL code• Use a simulation tool like e.g. ModelSim• Test bench to apply stimuli/test inputs to the VHDL code• Visual inspection through graphical output (waveform)• Self checking test benches (add code to check and verify result)

Test benches• Basic concept: Add a stimuli (input) to the design

under test and observe the outputs to verify correct behavior/functionality

• A characteristic of VHDL: test bench can be written in same language as the design to be verified.

• A VHDL TB can of course also contain errors introduced by the TB designer!

• Test benches are not to be synthesized, and can therefore use the entire VHDL language (e.g. after, wait for, write etc.)

• For proper simulation of FPGAs:– often more lines of verification code than for design source– can be more time consuming than design– Yet, often less effort spent on verification strategies and

documentation!

Partly adopted from: FPGA development best practice course by Espen Tallaksen, www.bitvis.no

The most basic test bench ”template”library ieee;use ieee.std_logic_1164.all;

entity test_UUT is -- empty entityend test_UUT

architecture testbenk_arch of test_UUT isComponent UUT:port(

…………………);end component;signal ………. signal ………. :=’0’; -- start value for inputs beginU1: UUTport map (………..);

STIMULI:processbegin…….wait;end process;end architecture;

(UUT = Unit Under Test)

Component declaration

Defines a signal for each port in the UUT

Component instantiation

Test sequencer to provide stimuli

Only test sequencer

Example of input signal/stimuli

Remember to initialize clkotherwise std_logic_vector à U

Alternatively

Example design Basic test bench

Test benches• Different levels / complexity– Generate input stimuli àmanual verification of output– Generate input stimuli à automatic verification of output– Use of verification components (advanced)

• Objective when writing a test bench– Verify design requirements for device under test– Sufficient functional coverage with minimum effort– Simple to write, understand and modify (by anyone)

• Modularity

– Simple to execute, debug and understand reports • Scripting, and well structured and meaningful log and alert functionality

Partly adopted from: FPGA development best practice course by Espen Tallaksen, www.bitvis.no

Test bench concepts

General needed features:• Logging mechanism

– informative, no attention required, progress reporting• Alert handling

– Messages that need attention (severity levels)• Verbosity control

– Enable or disable logging output• String handling and randomisation• Checks and awaits

Project specific • test sequencer• support procedures/processes

Basic test bench architecture

• Minimum required support– Logging– Alert handing & reports

• Additional support– Continuous actions not handled by sequencer (e.g. clock generator)

Partly adopted from: FPGA development best practice course by Espen Tallaksen, www.bitvis.no

Test sequencer

DUTSupport

Procedures & functions

Supportprocesses

Example of basic check functionality

When the specified condition is false, the ASSERT statement triggers and the report is issued

label: assert boolean_condition[ report string ] [ severity name ];

• Used to print messages at the simulation console when specified runtime conditions are met

• Defines one of four severity levels– Note: information about condition to the user– Warning: alerts conditions that are not expected but not fatal– Error: alert conditions that will cause the model to work incorrectly– Failure: alert conditions that are fatal

Will abort simulation

Assert statement example

Attributes• Attributes extract additional information about and object

(signal, variable , type, component)

• ‘image(x) and ‘value(s) simplifies reporting through text I/O

Now: predefined function that returns simulation time

Predefine attributes

NOT all supported by synthesis tools

Can for example be to check for setup violation

Attributes

clk

A5 ns

TB support procedures (Ex. of check)Example of checking for an expected value of an object of type unsigned

TEXTIO

• Provides declarations and subprograms for handling text (ASCII) files in VHDL (e.g. for logging)

• Three types of basic operation– Declaration of a file and its type– Opening and closing a file of a specified type– Reading and writing a file

• Data types to assist in text handling– Line : text buffer used to interface VHDL I/O and the file– File of type text: may only contains ASCII characters

File I/O

Alternative: Implicit file open

File_open()File_close()

File for storing ASCII

Declaration and open file

Writing

read_mode / append_mode

Example logging procedure

VHDL is strongly typed:Need to specify type of Characters enclosed in “ ”.

write is overloaded

Self-testing test benches• Contains a number of support procedures/process to improve efficiency

of test bench and perform automatic checks of relevant signals

• Alerts and relevant results should be clearly indicated

• Status / summary should be reported at the end

• Structured and readability: use procedures to hide details

• Visual inspection of timing diagrams often not needed (saves time)

• Other people can more easily maintain the code

• However, it is a demanding task to make a self-testing test bench!– If possible, write for reuse of procedures

• If available, consider using already available libraries

Write to file

UVVM utility library

• An open source library – available to anyone– More info at:

• https://uvvm.org– Can be downloaded from:

• https://github.com/UVVM

– Easy to integrate into your project

• Supports the most fundamental functionality of any structured VHDL test bench– Sufficient for simple test benches– Platform for more advanced TBs

• Purpose: standarize and qualify a set of good procedures => improve quality and efficiency

Some available and helpful procedures • report_global_ctrl()• report_msg_id_panel()• enable_log_msg()• disable_log_msg()• increment_expected_alerts()• log()• check_value()• check_value_in_range()• check_stable()• alert()• report_alert_counters()• to_string()• await_value()• await_change()• random()

https://github.com/UVVM/UVVM/blob/master/uvvm_util/doc/util_quick_ref.pdf

Basic example UVVM Basic test bench

Output when using UVVM

Output when using UVVM