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

Hi Lisa,

I am attaching the updated version. Please, see my comments below.

Thanks,
Dmitry

-----Original Message-----
From: Lisa Piper [mailto:piper@cadence.com] 
Sent: Wednesday, October 10, 2007 9:48 PM
To: Korchemny, Dmitry; Thomas.Thatcher@sun.com;
john.havlicek@freescale.com
Cc: sv-ac@eda-stds.org
Subject: RE: [sv-ac] call to vote on 1682

Hi Dmitry,

There is a reference to 16.8.4 that should be 16.18.3 in d4
[Korchemny, Dmitry] Fixed.

The global clocking past value functions are a special case of the
sampled
value functions, and therefore the regular restrictions imposed on the
sampled value function arguments apply  (see 16.8.4)."  

[Korchemny, Dmitry] Fixed.

I did not check the other references.

[Korchemny, Dmitry] Also fixed 19.11 -> 19.12

Some statement is needed w.r.t. the evaluation of the assertion at time
t=0 when future value functions exist.

[Korchemny, Dmitry] This statement is not quite clear to me. What is the
difference between time t=0 and other time moments?

Also, when does the attempt start and fail? This is important in terms
of understanding how the disable iff and VPI's and system tasks affect
it.  

[Korchemny, Dmitry] I changed the paragraph

"An action block of an assertion containing next value functions is
performed at the global clocking tick that
follows the assertion clock tick at which the final boolean expression
of the assertion is evaluated. This allows
the evaluation of the next value functions to be delayed until after the
next values of the signals referenced
have been computed."

to

"An evaluation attempt of an assertion containing next value functions
ends at the global clocking tick that follows the assertion clock tick
at which the final boolean expression of the assertion is evaluated,
This allows the evaluation of the next value functions to be delayed
until after the next values of the referenced signals have been
computed. Note however, that the behavior of the disable iff clause
remains consistent with its behavior for assertions without future value
functions (see 16.12): the completion of the property evaluation does
not include the additional global clocking tick."

I also think we need to say that past value functions are based on the
initial value, like sampled value functions. 

[Korchemny, Dmitry] I don't think that an additional explanation needs
to be added about the past value functions, because it is explicitly
stated that the global clocking past value functions are special cases
of the regular sampled value functions.

You state that future value functions can only be used in property
expressions. I think it should more explicitely state that they cannot
be used in assertion action blocks.

[Korchemny, Dmitry] Modified the statement:

"The use of these functions is limited to assertion features only. It
shall be an error to invoke these functions outside of property
expressions, this also implies that they shall not be used in assertion
action blocks."

You state that $past_glck equivalent to $past(sig, $gclk).  In 16.8.3,
it is stated "When these functions are used in an assertion, the
clocking event argument of the functions, if specified, shall be
identical to the clocking event of the expression in the assertion. In
the case of multiclock assertions, the appropriate clocking event for
the expression where the function is used is applied to the function."

Does this mean that to use these functions, my assertion or part of the
assertion must reference gclk?  Interestingly enough, the examples in
this document do meet this criteria.

[Korchemny, Dmitry] This restriction has already been relaxed in 1731,
and 1731 has already been approved. I changed its status temporarily to
feedback in order to implement the friendly amendments from the
champions.
  
Assertion system functions is 19.12, not 19.11 in d4.

[Korchemny, Dmitry] Fixed.

For simulation purposes, I think the only value here is if there is a
$tick defined. 

[Korchemny, Dmitry] It is not the only case when the future global
clocking functions are useful in simulation. Consider a test bench that
drives the signals with some delay. In this case using $tick as a global
clock will lead to inconsistent results: the internal signals will
already have their new values while the primary inputs will retain their
old value.

Lisa 



-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Korchemny, Dmitry
Sent: Tuesday, October 09, 2007 9:11 AM
To: Thomas.Thatcher@sun.com; john.havlicek@freescale.com
Cc: sv-ac@eda-stds.org
Subject: RE: [sv-ac] call to vote on 1682

Hi Tom,

I am attaching the updated version, see also my comments below.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Thomas Thatcher
Sent: Monday, October 01, 2007 10:28 PM
To: john.havlicek@freescale.com
Cc: sv-ac@server.eda-stds.org
Subject: Re: [sv-ac] call to vote on 1682

I vote no on 1682.

The following paragraph is still not clear:

    An action block of an assertion containing next value functions
    is performed at the time when all the next values are actually
    computed, that is, at the global clocking tick that follows the
    assertion clock tick at which the final boolean expression of the
    assertion is evaluated.

    First, the paragraph only says that the "action block" is delayed.
For
    accuracy, it should say that the "evaluation" of the assertion is
delayed
    as well.

    My suggestion:

    An action block of an assertion containing next value functions
    is performed at the global clocking tick that follows the
    assertion clock tick at which the final boolean expression of the
    assertion is evaluated.  This allows the evaluation of the next
value
    functions to be delayed until the after the next values of the
signals
    referenced have been computed.

[Korchemny, Dmitry] Rewrote it as you suggested, except for "until after
the next values ..." instead of "until THE after the next values ..."
	
   In addition, we could add further explanation that in a simulation
context,
   the function $future_gclk(sig) could be evaluated by the equivalent
   (@$gobal_clk ##1 $past_gclk(sig))

[Korchemny, Dmitry] I would state it as (@$gobal_clk ##1 sig). But the
rewriting rule is not that simple since a future value function may be
written inside a boolean expression. Therefore I don't think it is
feasible to provide the rewriting rule in the LRM (it would be complex
recursive algorithm).

I found this sentence from the first paragraph a little cryptic and hard
to
follow.

    These functions include the capability to access the sampled value
at
    the previous (resp. the next) global clock tick that precedes (resp.
    follows) immediately the timestep at which the function is called.

I don't think the "resp." abbreviation is good style for a standard. How
about:

    These functions include the capability to access the sampled value
at
    the global clock tick that immediately precedes or
    follows the timestep at which the function is called.	

[Korchemny, Dmitry] Rewrote it as you suggested.

Tom

John Havlicek wrote On 09/25/07 12:34 PM,:
> Hi Folks:
> 
> This is the call to vote on the proposal for 1682.
> The document on Mantis is 
> 
> GlobalCLockPastNextValuefunctions1682_070912_dk.pdf
> 
> Please vote if you are eligible.  See the details below.
> 
> J.H.
> 
>
------------------------------------------------------------------------
------
> 
> Ballot on Mantis 1682
> 
> - Called on 2007-09-25, final ballots due by 2007-10-02 T 23:59-07:00.
> 
> 
>  v[xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel)
>  v[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)     
>  n[---------x-xxx---------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
>  v[xx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
>  t[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freescale -
Chair)
>  v[xxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel -
Co-Chair)
>  v[xx-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[xxxxxx..............................] Johan Martensson (Jasper)
>  n[--------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
>  v[xxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
>  v[-xxxxxxx-x-xxxxx-x..................] Erik Seligman (Intel)
>  v[-x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor Graphics)
>  v[xx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
>  v[xxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun
Microsystems)
>    |------------------------------------ attendance on 2007-09-25
>  |-------------------------------------- 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)
> 		n = not valid voter
>                 t = chair eligible to vote only to make or break a tie
> 

-- 
------------------
Thomas J. Thatcher
Sun Microsystems
------------------

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, 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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, 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.

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