Subject: Re: Assertion Minutes 3/28/02
From: Richard Stolzman (richard@verplex.com)
Date: Tue Apr 02 2002 - 10:28:19 PST
Here are my votes... I am still reconciling the idea of using these
for simulation, formal, semiformal, and symbolic verification ... for
both assertions and/or event monitors.
>
> 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
a & b - Yes
c & d - No, not required, should be optional
Since messages will be used for formal verification tools, the
"simulation time" is not useful. In the case of counter-examples
or failure witnesses, "failure time" is very useful, but doesn't fit
the idea used in c & d. If c & d were expanded to make the
"failure at time" idea more flexible, c would be useful, d would
still be conditional (d is only useful for event monitoring in
simulation - not something to require in general).
Overall, No ... not 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, most messages follow tool-provider specific style guides, we
can recommend a format or info to be included ... I'm reluctant
to require.
>
>
> 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. Flexible message filtering should be allowed.
>
>
> Vote 4:
> If Vote 3 passes, is $quiet still required?
Yes... $fatal, $error, $warning, $info, $quiet provide a good set of
explicit messaging capability. $display, etc. extends capability. The
tool can provide the ability to filter the level of verbosity based on
these.
>
>
> 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.
>
Yes, these improve readability and conceptualization. If I'm asserting a
1-cold condition, I would rather not say "1-hot-not"... I understood
this will probably be hidden under a library (i.e. OVL), but it still
provides better semantic clarity. And in some cases, it simplifies the
coding.
>
> 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)
a - Yes.
b - On the fence... Put me down for whatever Harry decides.
c - On the fence... Put me down for whatever Harry decides.
>
>
> Vote 7:
> Should Antecedent/Consequent be postponed until SystemVerilog 3.1 to allow
> time to resolve semantic issues with VFV committee?
Yes
>
> --------------------------------------------
>
> 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
> ------------------------------------------------------
Richard Stolzman
Business Development Manager
Verplex Systems, Inc.
This archive was generated by hypermail 2b28 : Tue Apr 02 2002 - 10:30:50 PST