This blog post will be about the use of
the VHDL assert statement. The use of the assert statement is
demonstrated throughout the VHDL Test Bench Package. Also, in the
default instructions, several assert statements are used to terminate
the simulation when there is an error of some sort. Please refer to
the tb_pkg_body.vhd and template_tb_bhv.vhd files of the VHDL Test
Bench Package. You do not have to generate a test bench to see the
usage of the assert statements.
In the case of the VHDL Test Bench Package, the assert statement is used to check that the script, the user is feeding into the simulation, has the correct syntax. As the script is parsed and put into the linked list of commands, the existence of the command and the number of variables passed are checked. After the script is populated into the linked list, the variables are tested for existence as well. These checks are done before the simulation starts. The assert statement facilitates ending the simulation through the “failure” severity level. These assert statements are found in the tb_pkg_body.vhd file. The other level of checking that uses asserts is found in the <tb_name>_tb_bhv.vhd file. These asserts are checking the results of a command, or are in place to check the structure of a command like IF . The user should create asserts where needed in commands. These will have to be customization of the ones you find in the tb_bhv.vhd file and code snips (Code snips are now part of the Opencores distribution).
An assert is a VHDL language construct that if the statement that is passed evaluates to false, the body of the statement will execute. There is lots of information on the web about the VHDL assert construct. The body of the assert may contain a “report” field. This text field enables the code to print out a message to the simulation log. The other field is the “severity” field. It enables the command to exist in one of four levels, note, warning, error or failure. The levels enable the simulator to be configured to limit which levels will be reported and which will be ignored. The assert instruction looks like this:
When I code asserts I try to keep the <statement evaluating to true or false> as simple as possible. Usually “something = something else” is all that is needed.
The assert statement is usually a sequential statement. So most of the time it will be enclosed in a process, procedure or function. The placement of the assert statement in the code will determine when the assert will evaluate. So if the assert is in a clocked process, the assert will evaluate every clock edge the process and logic is sensitive to.
The assert is the “self checking” element provided by the VHDL language. I failed to present this in the “What is Self Checking” post. When you add asserts to your code, whether it be RTL or test bench code, you are implementing self checking. Implementing asserts in your RTL and test bench is highly recommended. Nothing like having a bunch of silent checkers watching your design or function and when there is a problem, you are able to inform the user of the problem.
In a design effort, which includes design and verification, the use of asserts is recommended in the following areas:
I have rarely used the assert with severity note. This is really of little use except for development debug. Even then I would use the test bench print() command instead. As I have stated in the Messages post, I believe messages should be minimized.
When using an assert statement to prove a complicated function, I create processes that emulate the function and produce an expected output. I then use an assert and check that the emulated value equals the real value. So, I reduce the evaluation statement to “emulate = real”. Though you can implement very complicated statements as the condition to the assert, why do that when you can implement in a process?
If you are not already using the VHDL assert construct, I hope this encourages you to get started. The assert is a very powerful and often under used language construct. For RTL it is an excellent way to make your RTL semi-self checking. For VHDL Test Bench package it is the best way to provide self checking of the stimulus file being read.
Assert!!
Sckoarn
In the case of the VHDL Test Bench Package, the assert statement is used to check that the script, the user is feeding into the simulation, has the correct syntax. As the script is parsed and put into the linked list of commands, the existence of the command and the number of variables passed are checked. After the script is populated into the linked list, the variables are tested for existence as well. These checks are done before the simulation starts. The assert statement facilitates ending the simulation through the “failure” severity level. These assert statements are found in the tb_pkg_body.vhd file. The other level of checking that uses asserts is found in the <tb_name>_tb_bhv.vhd file. These asserts are checking the results of a command, or are in place to check the structure of a command like IF . The user should create asserts where needed in commands. These will have to be customization of the ones you find in the tb_bhv.vhd file and code snips (Code snips are now part of the Opencores distribution).
An assert is a VHDL language construct that if the statement that is passed evaluates to false, the body of the statement will execute. There is lots of information on the web about the VHDL assert construct. The body of the assert may contain a “report” field. This text field enables the code to print out a message to the simulation log. The other field is the “severity” field. It enables the command to exist in one of four levels, note, warning, error or failure. The levels enable the simulator to be configured to limit which levels will be reported and which will be ignored. The assert instruction looks like this:
assert (<statement evaluating to
true or false>)
report ”Some Quoted text string
including escape characters”
severity <level>;
When I code asserts I try to keep the <statement evaluating to true or false> as simple as possible. Usually “something = something else” is all that is needed.
The assert statement is usually a sequential statement. So most of the time it will be enclosed in a process, procedure or function. The placement of the assert statement in the code will determine when the assert will evaluate. So if the assert is in a clocked process, the assert will evaluate every clock edge the process and logic is sensitive to.
The assert is the “self checking” element provided by the VHDL language. I failed to present this in the “What is Self Checking” post. When you add asserts to your code, whether it be RTL or test bench code, you are implementing self checking. Implementing asserts in your RTL and test bench is highly recommended. Nothing like having a bunch of silent checkers watching your design or function and when there is a problem, you are able to inform the user of the problem.
In a design effort, which includes design and verification, the use of asserts is recommended in the following areas:
- RTL: In the design, there should be asserts coded in the RTL for generic settings and limits, register contents outside legal bounds and any place the designer wants to ensure correctness. The RTL designer should strive to ensure users of their code get notification if something is wrong.
- Test Environment: In the test environment the use of the assert statement should be used to check user input and provide meaningful debug information.- Asserts should be in any command where checking results in a testcase could result in failure- Asserts should be used in BFM's where the address space has limits. (assess range checking)- Asserts can be used to output messages as to when a requirement has been seen to have been proven. Very good for DO-254 efforts.- Asserts can be used in Monitor BFM's to generate statistics or error/warning/failure messages.
I have rarely used the assert with severity note. This is really of little use except for development debug. Even then I would use the test bench print() command instead. As I have stated in the Messages post, I believe messages should be minimized.
When using an assert statement to prove a complicated function, I create processes that emulate the function and produce an expected output. I then use an assert and check that the emulated value equals the real value. So, I reduce the evaluation statement to “emulate = real”. Though you can implement very complicated statements as the condition to the assert, why do that when you can implement in a process?
If you are not already using the VHDL assert construct, I hope this encourages you to get started. The assert is a very powerful and often under used language construct. For RTL it is an excellent way to make your RTL semi-self checking. For VHDL Test Bench package it is the best way to provide self checking of the stimulus file being read.
Assert!!
Sckoarn
