Re: [sv-ac] RE: Draft proposal for 2476 (clarifications on system functions) posted

See below:
TO
A bit with value X or Z is not counted towards the number of ones.
The above functions are not restricted to be used only in assertions. The
functions $onehot, $onehot0, and $isunknown may be used in any context where
an expression of type bit is permitted. The function $countones may be used
in any context where an integer_type is permitted.

<In addition, several other categories of system functions are provided to
deal with value changes over time:
--- Sampled value functions: $sampled, $rose, $fell, $stable, $changed,
$past
--- Global clocking past value functions: $past_gclk, $rose_gclk,
$fell_gclk, $stable_gclk, $changed_gclk
--- Global clocking future value functions: $future_gclk, $rising_gclk,
$falling_gclk, $steady_gclk, $changing_gclk>
[Ben] It is not clear if those are not restricted to be used only in
assertions Should that be more explicit? I don't believe that the futre
functions make sense though... ??

The sampled value functions are described in 16.9.3. The global clocking
functions are described in 16.9.4.
In 20.13 (Assertion system functions) CHANGE
assert_boolean_

On Mon, Sep 13, 2010 at 8:34 AM, Seligman, Erik <erik.seligman@intel.com>wrote:

> Yes, I didn’t want to tackle that can of worms within this proposal…
>
>
>
> As for your original question: since this is a “less rigorous” part of the
> BNF, I was trying to create the simplest possible proposal that makes the
> syntax clear. I didn’t think introducing a complex hierarchy of function
> types was needed here.
>
>
>
> Do others on this list agree/disagree? It will be pretty easy to change if
> needed.
>
>
>
> *From:* Bresticker, Shalom
> *Sent:* Sunday, September 12, 2010 2:29 AM
>
> *To:* Dana Fisman; Seligman, Erik; sv-ac@eda.org
> *Subject:* RE: Draft proposal for 2476 (clarifications on system
> functions) posted
>
>
>
> It's also much bigger than SV-AC.
>
>
>
> Shalom
>
>
>
> *From:* Dana Fisman [mailto:Dana.Fisman@synopsys.com]
> *Sent:* Sunday, September 12, 2010 11:18 AM
> *To:* Bresticker, Shalom; Dana Fisman; Seligman, Erik; sv-ac@eda.org
> *Subject:* RE: Draft proposal for 2476 (clarifications on system
> functions) posted
>
>
>
> Thanks Shalom.
>
>
>
> I don’t think these are good enough reasons, but I understand this is a
> separate issue…
>
>
>
> Regards,
>
> Dana
>
>
>
> *From:* Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> *Sent:* Sunday, September 12, 2010 11:14 AM
> *To:* Dana Fisman; Seligman, Erik; sv-ac@eda.org
> *Subject:* RE: Draft proposal for 2476 (clarifications on system
> functions) posted
>
>
>
> There were several reasons, I think:
>
>
>
> 1. There were very many, and they would have made Annex A much bigger.
>
> 2. These BNFs were less rigorous.
>
> 3. These parts of the language had much more parts whose implementation
> by vendors was not mandatory, and there were much more vendor-specific
> extensions.
>
>
>
> Regards,
>
> Shalom
>
>
>
> *From:* Dana Fisman [mailto:Dana.Fisman@synopsys.com]
> *Sent:* Sunday, September 12, 2010 9:50 AM
> *To:* Bresticker, Shalom; Dana Fisman; Seligman, Erik; sv-ac@eda.org
> *Subject:* RE: Draft proposal for 2476 (clarifications on system
> functions) posted
>
>
>
> Why?
>
>
>
> *From:* Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> *Sent:* Sunday, September 12, 2010 10:46 AM
> *To:* Dana Fisman; Seligman, Erik; sv-ac@eda.org
> *Subject:* RE: Draft proposal for 2476 (clarifications on system
> functions) posted
>
>
>
> Regarding why the assertion system functions are not in Annex A, this is
> deliberate, not an oversight.
>
>
>
> All the syntax excerpts from Clauses 20-22 (system functions and tasks,
> compiler directives) are not in Annex A.
>
>
>
> Regards,
>
> Shalom
>
>
>
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of *Dana
> Fisman
> *Sent:* Sunday, September 12, 2010 8:53 AM
> *To:* Seligman, Erik; sv-ac@eda.org
> *Subject:* [sv-ac] RE: Draft proposal for 2476 (clarifications on system
> functions) posted
>
>
>
> Hi Erik,
>
>
>
> Just one comment -
>
>
>
> Why not separate the BNF for assert_boolean_functions to several
> categories, each capturing a syntactic entity all of whose system functions
> can be used interchangeably from syntax perspective (i.e. all return the
> same type of expression and are allowed in same places). Isn’t that the
> purpose of the BNF (to give quick answer on what can be used where)? Also,
> why isn’t this in Annex A (originally and in the proposal)
>
>
>
> Thanks,
>
> Dana
>
>
>
>
>
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of *Seligman,
> Erik
> *Sent:* Saturday, September 11, 2010 12:25 AM
> *To:* sv-ac@eda.org
> *Subject:* [sv-ac] Draft proposal for 2476 (clarifications on system
> functions) posted
>
>
>
> Hi guys—
>
> I just posted a first draft of the proposal for Mantis
> http://www.verilog.org/mantis/view.php?id=2476, at
> http://www.verilog.org/mantis/file_download.php?file_id=4536&type=bug .
> Please take a look & send comments.
>
>
>
> Thanks!
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> ---------------------------------------------------------------------
>
> Intel Israel (74) Limited
>
>
>
> This e-mail and any attachments may contain confidential material for
>
> the sole use of the intended recipient(s). Any review or distribution
>
> by others is strictly prohibited. If you are not the intended
>
> recipient, please contact the sender and delete all copies.
>
> ---------------------------------------------------------------------
>
> Intel Israel (74) Limited
>
>
>
> This e-mail and any attachments may contain confidential material for
>
> the sole use of the intended recipient(s). Any review or distribution
>
> by others is strictly prohibited. If you are not the intended
>
> recipient, please contact the sender and delete all copies.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.