Subject: Re: Assertion Minutes 3/28/02
From: Adam Krolnik (krolnik@lsil.com)
Date: Tue Apr 02 2002 - 11:11:40 PST
>Vote 1:
What does d) mean? There may be more than one time point that the
assertion is executing if there is a sequence in the assertion.
There is only one time at which it fails.
There is one thing missing - the severity.
Vote for a, b, c and e (the severity.)
Maybe this should be only for simulators...
>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 2:
I thought this vote was for, "Should there be a standard error
message format" (for example generated from the $error() call?
Your example left out the severity as well. There is no value
add in different error message formats!
Vote YES for a standard error message format.
>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 3:
I though there was a request to enable printing of a message when
there was an empty else (e.g. else ;) so that missing messages
could be shown?
Vote NO - error message should not be easy to disable.
>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 4:
Vote YES for $quiet regardless of #3.
>If Vote 3 passes, is $quiet still required?
>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 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)
VOTE for c. Having implemented this function in verilog, using
casez and seeing the benefits of having a don't care comparator
function, the usefulness of don't care matching far outweighs
any fear, uncertainty and doubt over implementing this.
If simplicity in writing assertions is a worthy goal, this is
a key feature to vote in - without it produces more code a designer
must write and get correct.
>Vote 7:
>Should Antecedent/Consequent be postponed until SystemVerilog 3.1 to >allow time to resolve semantic issues with VFV committee?
Vote YES.
From the discussions with Erich it appears the VFV has solutions
in this area.
--------------------------------------------
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Tue Apr 02 2002 - 11:13:24 PST