VHDL Test benches How to simulate VHDL code Use a simulation - PowerPoint PPT Presentation

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; Only test sequencer use ieee.std_logic_1164.all; entity test_UUT is -- empty entity (UUT = Unit Under Test) end test_UUT architecture testbenk_arch of test_UUT is Component UUT: port ( Component declaration ………………… ); end component; Defines a signal for each port in signal ………. the UUT signal ………. :=’0’; -- start value for inputs begin U1: UUT Component instantiation port map (………..); STIMULI: process begin Test sequencer to provide stimuli ……. wait; end process; end architecture;

Example of input signal/stimuli Remember to initialize clk otherwise std_logic_vector à U Alternatively

Basic test bench Example design

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 Test sequencer Support DUT processes Support Procedures & functions 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

Example of basic check functionality label: assert boolean_condition [ report string ] [ severity name ]; When the specified condition is false, the ASSERT statement triggers and the report is issued

Assert statement example • 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

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

Attributes Can for example be to check for setup violation clk A 5 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 Declaration and open file File_open() File_close() File for storing ASCII Alternative: Implicit file open read_mode / append_mode Writing

Example logging procedure write is overloaded VHDL is strongly typed: Need to specify type of Characters enclosed in “ ”.

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 • Write to file 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 •

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