Subject: Re: [sv-ac] 17.9: System functions: $onehot/$onehot0
From: Adam Krolnik (krolnik@lsil.com)
Date: Tue Apr 22 2003 - 11:46:30 PDT
Here are the minutes from voting for the original definitions.
In here is the definition,
$onehot0() - at most one bit is 1
Passes unanimously
$onehot() - one and only 1 bit is 1
Passes unanimously
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
-------- Original Message --------
Subject: Assertion Minutes 3/28/02
Date: Tue, 2 Apr 2002 11:04:17 -0500
From: "Tom Fitzpatrick" <fitz@co-design.com>
Reply-To: <fitz@co-design.com>
To: <assertion@eda.org>
CC: "Bassam Tabbara" <bassam@novas.com>, "Erich Marschner" <erichm@cadence.com>,
"Gail Dagan" <gail.m.dagan@intel.com>
Hi Everyone,
Here are the minutes from last meeting. There were a few items that we
decided to vote on via email, which I list at the end. Please respond with
your votes by 5pm EST.
Attendance:
Harry Foster
Richard Stolzman
David Lacey
Peter Flake
Tom Fitzpatrick
Erich Marschner
Simon Davidmann
Tom Anderson
Adam Krolnik
Prakash Narain
Bassam Tabbara
Notes:
Fitz to include Erich's and Peter's updates to Expression Sequences
Discussion of error message reporting.
Fitz proposal of 3/26
Harry: what information should be displayed in the message?
Erich: the issue is how to control the display - should this be outside the
language? Can the behavior of when the message gets displayed be controlled
on the command-line.
Erich: using "else ;" is a baroque method to suppress an error message.
Adam: the most common operation will be to find errors, so the default
should be to display the message.
Erich/Harry: assertions are commonly used for coverage monitors
Adam: It's more costly to miss a message when looking for errors than for
looking at coverage points.
Proposal: Command-line switch to control behavior when no else clause is
present. Default operation should be on by default.
Fitz to clarify proposal. Vote via email.
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.
Voting on contents of string will be separate item.
$isunknown() - signal has X's in it ::= ^sig === 1'bx
Objects: Prakash, TomA, Fitz,
Passes: 6/3
$onehot0() - at most one bit is 1
Passes unanimously
$onehot() - one and only 1 bit is 1
Passes unanimously
$onecold() - one and only 1 bit is 0
Fails 5-4
$onecold1() - at most one bit is 0
Fails 5-4
$inset(sig, values) - sig in in values
Passes
$insetz(sig, values) - sig in values, including don't care
Emails
$outset(sig, values) - sig is not in list of values
Fails
$outsetz(sig, values) - sig is not in list, including don't care
Fails
Erich: should these be $functions or Verilog functions (requiring `include)?
If they are $functions, the standard must be revised to include new ones.
Harry/TomA: Supporting these as an extensible library is preferable.
Erich: Verilog functions would be more likely to be synthesizable
Adam: Having them built-in does not preclude adding to them later
Prakash: There must be a specific name identifiable with the functions
Erich: We should define a library. A small number of $functions can be
mapped to library functions.
Fitz/Prakash: These functions may be used outside of assertions.
Flake: It would require extra work by the tools
TomA: Limit it to a small number of functions. Avoid "feature creep"
Functions to return single bit 0 or 1.
Erich proposed $inset with and without don't care semantics.
Email vote on semantics of don't care
Email vote: Should all functions have complements
Antecedent/Consequent:
What does this mean?
assert(a triggers(done) triggers (foo))
If a is true and done is false, does it pass or fail?
Erich: logical implication is much more involved than has been addressed
here. Should there be "doesn't trigger", or negation of sequences.
Harry/Prakash: They are uncomfortable about whether all semantics issues
have been fully addressed. Propose postponing antecedent/consequent until
SystemVerilog3.1.
Bassam: Sequences should be first-class objects in the language.
Erich: We need to decide whether or not to be compatible with VFV committee.
If there are issues, we should delay and work with the VFV committee.
Erich to provide examples of how to model accept/reject using Sugar.
--------------------------------------
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 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 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 4:
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 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 7:
Should Antecedent/Consequent be postponed until SystemVerilog 3.1 to allow
time to resolve semantic issues with VFV committee?
--------------------------------------------
Please have all votes in to me by 5pm EST on Wednesday. I'll review the
results at the start of Thursday's meeting, then we'll discuss resetting
assertions.
Thanks,
-Fitz
------------------------------------------------------
Tom Fitzpatrick
Director of Technical Marketing
Co-Design Automation, Inc.
------------------------------------------------------
Email: fitz@co-design.com Mobile: (978)337-7641
Tel: (978)448-8797 Fax: (561)594-3946
Web: www.co-design.com
www.superlog.org
------------------------------------------------------
SUPERLOG = Faster, Smarter Verilog
------------------------------------------------------
This archive was generated by hypermail 2b28 : Tue Apr 22 2003 - 11:47:39 PDT