Subject: RE: Assertion Messages
From: Tom Fitzpatrick (fitz@co-design.com)
Date: Tue Mar 26 2002 - 12:00:27 PST
Should the default message include a severity (which we already agreed
should be "error")?
What other information should be included in the default message? I would
expect at least:
File name
Line number
Assertion name (full hierarchical name, if specified)
Simulation time of failure
I think that this means we have to describe a "status string", such as:
"Assertion [<name>] (<file>:<line>) failed at time <time>. "
The actual format/content of the status string can be tool dependent, but we
should agree on the pieces of information that are required.
Each of the message tasks shall be defined to print
"<Severity>: <status string> <message>"
The default error message is therefore:
ERROR: Assertion top.u1.a1 (myfile.slg:7) failed at time 10.
For our little example, which I've updated a bit:
a1: assert (a) // assume this is myfile.v line 15
else # 10
if (b) #10 $fatal(2, "foo at %0t",$time);
else @clock $info("bar at %0t",$time);
When a is false, if b is true 10 time units later, we will print
FATAL: Assertion top.u1.a1 (myfile.v:15) failed at time 10. foo at 30
If b is false, we will print
INFO: Assertion top.u1.a1 (myfile.v:15) failed at time 10. bar at 40
I realize that this doesn't handle the case where you have an else clause
that does not contain a severity systask, but I can't really see any clean
way around it. You have to know what, if anything, to print immediately when
the assertion fails, so the only reasonable thing to do would be to print
out the default error message when the assertion fails. That means that, in
this case, we'd print out 2 messages
ERROR: Assertion top.u1.a1 (myfile.v:15) failed at time 10.
FATAL: Assertion top.u1.a1 (myfile.v:15) failed at time 10. foo at 30
OR
ERROR: Assertion top.u1.a1 (myfile.v:15) failed at time 10.
FATAL: foo at 30
There's no good way to define how the error gets displayed by default when
an assertion fails, and also to specify that the default status string be
included in the severity systasks.
Seems to me the best thing is to recommend that there always be a severity
systask in the else clause (actually, in each branch of the else clause) and
let lint tools do the check. I don't see a clean way, from the language
design perspective, to address all of the goals, and I believe that worrying
about a missing systask in the else is the lowest priority and can best be
handled by linting.
-Fitz
> -----Original Message-----
> From: owner-assertion@server.eda.org
> [mailto:owner-assertion@server.eda.org]On Behalf Of Harry Foster
> Sent: Tuesday, March 26, 2002 11:36 AM
> To: David Lacey; assertion@server.eda.org
> Subject: RE: Assertion Messages
>
>
> David's point about a uniform method of reporting default
> information in the design flow is important.
>
> The problem could be simplified by formally defining
> the format of the default message (i.e., assert with no
> else). Then, formally define the $fatal, $error, $error
> and $info message. In other words, the default
> information would be "consistently" reported as part
> of these system task. If no system task is called in
> an 'else' statement, then no default information is
> reported.
>
> -Harry
>
> > -----Original Message-----
> > From: owner-assertion@eda.org [mailto:owner-assertion@eda.org]On Behalf
> > Of David Lacey
> > Sent: Tuesday, March 26, 2002 10:17 AM
> > To: assertion@eda.org
> > Subject: Re: Assertion Messages
> >
> >
> > 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 - 11:59:34 PST