Subject: RE: Assertion Minutes 3/28/02
From: Harry Foster (harry@verplex.com)
Date: Tue Apr 02 2002 - 08:36:37 PST
> --------------------------------------
> 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
>
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 - 08:36:47 PST