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:

–

• ften 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 entity end test_UUT architecture testbenk_arch of test_UUT is Component UUT: port ( ………………… ); end component; signal ………. signal ………. :=’0’; -- start value for inputs begin U1: UUT port map (………..); STIMULI: process begin ……. 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 clk

• therwise 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

DUT

Support Procedures & functions Support processes

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 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

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
• f 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