Subject: RE: Assertion Minutes 3/28/02
From: Erich Marschner (erichm@cadence.com)
Date: Tue Apr 02 2002 - 09:00:19 PST
Tom,
Thanks for cc:ing me on the minutes. I don't think I'm getting any email from the reflector yet. When I subscribed, I got a message back that my subscription needed to be approved by the list owner. I've never gotten final confirmation. Are you the owner?
Regarding this:
| Adam: We should define the contents of the error message string.
| Erich: Some simulators have their own formats, so requiring
| a specific format will be probematic.
My point was not that a given simulator has its own format, but rather that simulators today implement multiple languages, and potentially conflicting error message format requirements from different languages would limit the ability of implementors to provide the seamlessly integrated solution that customers want. Better for each language to specify what information is required in the string, so the implementor can take the superset of all the requirements and define a standard format for error messages coming from any language in the mixed language simulator.
My votes:
| --------------------------------------
| 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
No. (I would vote Yes for a,b, but since the assertions could be used for formal verification also, c,d don't apply in all cases, so I have to vote against the proposal as stated.)
|
| 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.
No. (There will always be differences in different simulators' outputs. This wouldn't solve the problem.)
| 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.
| Vote 4:
| If Vote 3 passes, is $quiet still required?
Abstain. No opinion.
| 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.
| 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)
Abstain. No opinion.
| Vote 7:
| Should Antecedent/Consequent be postponed until
| SystemVerilog 3.1 to allow
| time to resolve semantic issues with VFV committee?
| --------------------------------------------
Yes.
Regards,
Erich
-------------------------------------------
Erich Marschner, Cadence Design Systems
Senior Architect, Advanced Verification
Phone: +1 410 750 6995 Email: erichm@cadence.com
Vmail: +1 410 872 4369 Email: erichm@comcast.net
This archive was generated by hypermail 2b28 : Tue Apr 02 2002 - 09:01:35 PST