Subject: Re: Assertion Messages
From: David Lacey (dlacey@rsn.hp.com)
Date: Tue Mar 26 2002 - 08:17:09 PST
Tom makes a good point. I would suggest a slightly different
alternative. I agree that the default message should print if no else
if given. I would also add that the $fatal, $error, $warning, and $info
messages always start with the default message. In Tom's example, the
else is present, so when the assertion fails, no default message is
printed immediately. However, only the delays and the value of 'b' is
determined and we determine which path we take ($fatal or $info), then
the default message prints at the same time either $fatal/$info is
printed as a prefix to their message.
The reason I suggest this is because it makes it easier to parse log
files looking for assertions that failed. If we do not include the
default error message as a prefix on the four system tasks we are
presenting, then getting a common format for assertion output requires
getting all designers on the team to do it individually, which never
happens.
So in summary, the new statement would be:
"If the else is omitted a default error message is written if the assertion
fails... If the else is present, the default message is not printed. User specific information may be displayed by including a system task to do so, such as $fatal, $error, $warning, $info. If one of these system tasks is used in the else path, then the default message is printed prior to the message provided by the system task."
or something like this.
David
Tom Fitzpatrick wrote:
>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 : Tue Mar 26 2002 - 08:23:58 PST