Subject: Assertion Messages
From: Tom Fitzpatrick (fitz@co-design.com)
Date: Mon Mar 25 2002 - 13:37:55 PST
The original spec said:
"If the else is omitted a default error message is written if the assertion
fails, such as
Run-time Warning: myfile.slg:7 Assertion assert_foo failed at time 105
If the else is present, no message is written unless the statement contains
a system task to do so, such as $fatal, $error, $warning, $info."
Consider:
assert (a)
else # 10
if (b) #10 $fatal(2, "foo");
else @clock $info("bar");
With the original spec, if a is false, we wait 10 and check b. If b is true,
we wait another 10 and print "FATAL: foo". If b is false, we wait until
clock and print "INFO: bar".
Now consider the new spec we approved at the last meeting:
"If the else is omitted a default error message is written if the assertion
fails... If the else is present, the default message is still printed when
the assertion fails. Additional information may be displayed after the
default message by including a system task to do so, such as $fatal, $error,
$warning, $info."
The issue is that we don't know what severity to make the default message,
nor do we really know when to print it. The assertion fails when a is
evaluated false, so we could do something like:
ERROR: Assertion Failed a1 (myfile.v/18) at time 10
FATAL: foo
or
ERROR: Assertion Failed a1 (myfile.v/18) at time 10
INFO: bar
but I don't really like that. I also don't want to do anything hokey in the
language like try to make $fatal et.al. mutually exclusive in else
statements.
Therefore, I propose we go back to the original spec, which only prints out
a default message if there is no else statement. Suppression of the message
can be accomplished by simply adding "else ;" We did agree that the default
severity should be ERROR, so the new default message should be something
like:
Run-time Error: myfile.slg:7 Assertion assert_foo failed at time 105
I have a few ideas about how we might be able to control things a bit
better, but they involve adding new format specifiers and a few other things
that would affect the entire SystemVerilog language. Unfortunately, we don't
have time to look at them effectively, and the SystemVerilog committee
definitely doesn't have time to look at them, so we should just defer them.
I'd like to have a vote on this via email prior to Thursday, so please get
your votes back to me by 5pm EST on Wednesday. I'll allocate a minimal
amount of time for further discussion on this at Thursday's meeting.
Thanks,
-Fitz
+----------------------------------+------------------------------------+
| Tom Fitzpatrick | Tel: 1 978 448 8797 |
| Director of Technical Marketing | Mobile: 1 978 337 7641 |
| Co-Design Automation, Inc. | email: fitz@co-design.com |
+----------------------------+-----+------------------------------------+
| Web: www.co-design.com | Latest News: |
| www.superlog.org | http://www.co-design.com/news/index.htm |
+----------------------------+------------------------------------------+
| SUPERLOG = Faster, Smarter Verilog |
+-----------------------------------------------------------------------+
This archive was generated by hypermail 2b28 : Mon Mar 25 2002 - 13:37:08 PST