Subject: RE: Assertion Minutes 3/28/02
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Tue Apr 02 2002 - 09:27:46 PST
> From owner-assertion@eda.org Tue Apr 2 08:43:16 2002
> From: "Harry Foster" <harry@verplex.com>
>
> > --------------------------------------
> > Issues for Voting
> > --------------------------------------
> > Vote 1:
> > Data to be required in default message
> > a) assertion hierarchical name
> > b) file/line of assertion statement
> > c) simulation time at which assertion fails
> > d) simulation time at which assertion is executed
> >
Most of our simulations run in batch mode with Perl scripts
parsing the results looking for errors & warnings. It's
easier to pick out the assertion messages if they are on
one line and have a "splitable" format e.g.:
{<name>:<value>;}
e.g.:
Assertion: "broken" ; Level: error ; File: /mydes/new.v; Line: 200; Expression: a==b; Time: 1002ns;
- which splits on ';' and then ':'. Implementors can add more data
fields without breaking the basic format.
If folks want it pretty-printed I would suggest that tools accept
an assertion message format string e.g.:
sim -afrmt="Assertion (%A) - %N, %F:%L %X at time %T" ...
Giving the following instead of the above:
Assertion (error) - broken, /mydes/new.v:200 a==b at time 1002ns
Regards,
Kev.
> I vote for (a), (b) and (d)
>
> > Vote 2:
> > Should there be a standard string embedded in all assertion
> > status messages,
> > such as:
> > "Assertion [<name>] (<file>:<line>) failed at time <time>. "
> > NOTE: Some tools have their own standard format for reporting file/line
> > information and severity for messages.
>
> >From a user's perspective--this would be preferable (although I would
> not use the word "failed" in the default message. However, I feel
> that it is highly unlikely we could get this requirement through
> any IEEE standards effort. Hence, I will vote NO.
>
> >
> > Vote 3:
> > Should the printing of a message be controlled by a command line switch.
> > Proposal:
> > [Immediate Assertions section] change "If the else is omitted a default
> > error message is written if the assertion fails." to "If the else is
> > omitted, a default error message is written if the assertions
> > fails unless a
> > command-line option is enabled to suppress it."
> >
>
> Yes--provided the default is to print the message and the user has to
> disable this feature (i.e., exactly the way you have it worded).
>
> > Vote 4:
> > If Vote 3 passes, is $quiet still required?
>
> Yes--need finer grain of control.
>
> > Vote 5:
> > Should there be a complement of each approved system function?
> > i.e., since we passed $onehot, should there be $onecold?
> > NOTE: You must vote either for ALL functions to have a complement or for
> > NONE to have a complement.
>
> NO--complement is not necessary.
>
> >
> > Vote 6:
> > For $inset/$member, which matching semantics should be used?
> > a) exact match ($inset)
> > b) use casex semantics ($insetx)
> > c) use casez semantics ($insetz)
> >
>
> Only (a) -- X should be thrown out of the language (RTL) due to
> its optimistic behavior in RTL simulation (most respins
> due to initialization bugs are a result of X-state optimism).
> People should not be crafting their RTL to trap X's just
> to satisfy an artifact of RTL simulation (i.e., they should
> be focusing on modeling functional behavior). When
> will people every learn that X in an RTL model is horrible!!!!
>
> (Ok, I'm off my soap box now....). ;-)
>
> > Vote 7:
> > Should Antecedent/Consequent be postponed until SystemVerilog 3.1 to allow
> > time to resolve semantic issues with VFV committee?
>
> Yes--Antecendent/Consequent should be postponed until SystemVerilog 3.1.
>
> -Harry
>
>
>
This archive was generated by hypermail 2b28 : Tue Apr 02 2002 - 09:30:31 PST