Subject: Re: Assertion Minutes 3/28/02--votes
From: Bassam Tabbara (bassam@novas.com)
Date: Tue Apr 02 2002 - 12:15:13 PST
Hi Tom and all,
Here are 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
Vote 1: No.
Motivation: We need all of the above and more ... e.g. for (c), (d) in a
formal tool these would have to be "... clock (%s) cycle count (%d)...",
may be also event syncs ... many more things ...
> 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.
Vote 2: No.
Motivation: Leave "defaults" up to tool's operational semantics,
options, utilities ... define how user can -explicitly- say what he/she
wishes (of course tool can later override :-)!).
> 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."
Vote 3: No.
Motivation: see above.
> Vote 4:
> If Vote 3 passes, is $quiet still required?
Vote 4: No.
Motivation: does not seem to be a crucial "primitive" for user right now
... (lack of $display is good enough...).
> 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.
Vote 5: No.
Motivation: no real need for 0/1 duals.
> 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)
Vote 6: Yes, all.
Motivation: All of (a), (b), (c). We need to support -don't care- (of
course x's and z's are artifacts (and rather deadly as Harry asserts
:-)!), I really mean "-"... but we have to live with x/z).
> Vote 7:
> Should Antecedent/Consequent be postponed until SystemVerilog 3.1 to allow
> time to resolve semantic issues with VFV committee?
Vote 7: Yes.
Motivation: Many trade-offs involved. Not sure any one choice would be
sufficient ... need more consideration.
Thanks.
-Bassam.
P.S. I am also not on the email list, please keep cc-ing me, thx !
-- Dr. Bassam Tabbara Technical Manager, R&DNovas Software, Inc. bassam@novas.com (408) 467-7893
This archive was generated by hypermail 2b28 : Tue Apr 02 2002 - 12:16:31 PST