How to write a test bench that will fail if some outputs are not as expected ?

[tigrou]

Hello,

In verilog, it is possible to write test benches that set input ports to some values and print the output (to manually check modules are working correctly).

Is it possible to explicitly specify in the test bench what values you expect as output, and the test to fail if those values are not met ?

For example let's say I write a module that has A and B as inputs and C as output.
I would like to check that C is same as what is defined in the table below.

A B C
0 0 0
0 1 0
1 0 0
1 1 1

While searching info about GTKWave (and possible ways to do what I explain above) I have found this screenshot which show some values in red. Are those values because of test that does not meet some requirements ?

[rstofer]

There are a couple of ways that I know about.  No doubt there are others...

      if <some conditional test> then
        write(<some message>);
      end if;

OR
        assert <some conditional test> -- if the test is true, the following report and severity statements are not performed
          report <some message> -- report the failure
          severity failure;  -- stop the test bench

I suggest looking up the assert statement on the Internet, it's pretty handy


The signals are in red until they are defined.  Early on, the value isn't known.

[tigrou]

Assert and other tests : thanks for info.

The signals are in red until they are defined.  Early on, the value isn't known.

Yes, in the example I provide, signals are not defined yet. That is why (AFAIK)  there is a "xx..." label on data.
I have found some examples of red signals in GTKWave with some data defined (first page).

I took a look at GTKWave manual for more info (what red means) but could not find anything.

[rstofer]

Look at i_wbs_cyc and note that it changes from red to green at the leading edge of the rst signal as do many other signals.  Prior to reset, the values weren't defined and they're shown as both high and low in red.  This is pretty common for simulators and it's also true for processes that use reset to initialize a signal.

The xxxxxxxx is kind of redundant but is probably shown just to be pedantic.  I don't understand the 00xxxxxx but apparently the high two bits are predefined.