RE: [sv-ac] call to vote on 1757

I vote no for the following reason (sorry!):  I think it is VERY
CONFUSING to be calling this a "reset property" and then calling the
condition a "disable condition".  Especially when the disable iff
condition is called the "reset condition".  Perhaps a way around this is
to call this an "override" or "interupt" or "early termination clause".
And in fact, the accept_on and reject_on conditions don't disable the
assertion, they cause it to pass or fail. 

 

 

Additional comments:

 

1. Table 16-25 the reference is not exact  (if...else)  -> if-else in d4
and more significantly your text has a line for -> and <-> that is blank
in the replacement. (seems to be dependent on that other proposal)

 

2. There are a couple of issues with the following:

 

h) A property is a reset if it is of the following forms :

 accept_on(expression_or_dist) property_expr

 reject_on(expression_or_dist) property_expr

where the expression_or_dist is called the disable condition.

 

Issue a)  if you follow the format of existing text for other
letters(see e or f for example), it should read (ignore unintended font
changes):

 

h) A property is a reset if it has either the form is of the following
forms:

 accept_on(expression_or_dist) property_expr

 

or the form

 

 reject_on(expression_or_dist) property_expr

 

where the expression_or_dist is called the disable condition.

 

   Issue b) note in draft 4 that in the statement "where the
expression_or_dist is called the disable condition" that
expression_or_dist is now in times new roman italic instead of courier.
This means you can't italicize "disable condition" to differentiate it.


 

3. This is wrong if the last sentence is also comparing to disable iff:
Like disable iff, reject_on_and_accept_on_expressions may contain
sampled value functions (see

16.8.3). The clock argument shall be explicitly specified. The
expressions shall not contain any reference to

local variables and the sequence methods_ended, triggered_and_matched__
_ _

 

I think we should avoid the analogy to disable iff.  How about:

 

reject_on_and_accept_on_expressions may contain sampled value functions
(see

16.8.3). . If a sampled value function is

used in the reset expression, the sampling clock must be explicitly
specified in its actual argument list as

described in 16.8.3.  The expressions shall not contain any reference to

local variables and the sequence methods_ended, triggered_and_matched

 

This has the advantage of not confusing it with disable iff.  They are
not the same since disable iff can reference triggered. The new wording
that references 16.8.3 for sampling of a sampled value function was a
cut and paste from the description of this for disable iff.

 

4. There are several references to "property_expr" in the text that
should be italicized (new rule I think)

 

5. Should the references to "property" be "property_expr" in the
following: 

 "The semantics of_reject_on(expression) property are the same as
not(accept_on(expression) not(property))."

 

 

 

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of John
Havlicek
Sent: Monday, October 29, 2007 1:24 PM
To: sv-ac@eda.org
Subject: [sv-ac] call to vote on 1757

 

Hi Folks:

 

This is the call to vote on the revised proposal for 1757.

 

The document on Mantis is 

 

  AcceptRejecton1757.071024.pdf

 

Please vote if you are eligible.  See the details below.

 

J.H.

 

------------------------------------------------------------------------
----------

Ballot on Mantis 1757

 

- Called on 2007-10-29, final ballots due by 2007-11-05 T 23:59-08:00.

 

 v[xxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel)

 v[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)     

 n[------------x-xxx---------x-x-xxx-x---x] Surrendra Dudani (Synopsys)

 v[xxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)

 t[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale -
Chair)

 v[xxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel -
Co-Chair)

 v[xxxxx-xxx-x--xx--xxxxx----------xx-xxxx] Manisha Kulshrestha (Mentor
Graphics)

 n[--------------------xxxxx-------x-xx-x-] Jiang Long (Mentor Graphics)

 n[------------x--xxx.....................] Joseph Lu (Altera)

 v[xxxxxxxxx..............................] Johan Martensson (Jasper)

 n[-----------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)

 v[-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)

 v[-xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)

 n[----x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor Graphics)

 v[xxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)

 v[xxxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun
Microsystems)

   |--------------------------------------- attendance on 2007-10-23

 |----------------------------------------- voting eligibility for this
ballot

|------------------------------------------ email ballots received

 

        Legend:

                x = attended

                - = missed

                r = represented

                . = not yet a member

                v = valid voter (2 out of last 3 or 3/4 overall)

                n = not a valid voter

                t = chair eligible to vote only to make or break a tie

 

 

 

-- 

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.

 


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