[sv-ac] RE: Additional feedback on 3213

Hi Scott,

Well, next take: http://www.eda-stds.org/mantis/file_download.php?file_id=5107&type=bug.

I tried to express this in a more formal and accurate way, without duplicating of an expression sampled value for each sampled value function.

I modified the following parts of the definition of a sampled value:

- Sampled values of automatic variables (see 16.15.6), local variables (see 16.10), and active free checker variables (see 17.7.2) are their current values. When a past or a future value of an active checker variable is referred by a sampled value function (see 16.9.3 and 16.9.4), this value is sampled in the Postponed region of the corresponding past or future clock tick.
...
- A sampled value of sequence methods triggered and matched (see 16.14.6) are defined as current values returned by these methods. When a past or a future value of a sequence method is referred by a sampled value function (see 16.9.3 and 16.9.4), this value is sampled in the Postponed region of the corresponding past or future clock tick.

I replaced mentions of the Postponed region in sampled value function definitions with a reference to the above text. I also removed the explanation of the Postponed region sampling along with the illustrating example from 16.9.3.

Thanks,
Dmitry

-----Original Message-----
From: Little Scott-B11206 [mailto:B11206@freescale.com]
Sent: Thursday, May 26, 2011 15:27
To: Korchemny, Dmitry; 'sv-ac@eda-stds.org'
Subject: RE: Additional feedback on 3213

Hi Dmitry:

See my comment below.

Thanks,
Scott

> -----Original Message-----
> From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> Sent: Wednesday, May 25, 2011 8:38 AM
> To: Little Scott-B11206; 'sv-ac@eda-stds.org'
> Subject: RE: Additional feedback on 3213
>
> Hi Scott,
>
> Thank you for your comments. I updated my proposal and will upload it
> shortly.
>
> Please, see my comments below.
>
> Thanks,
> Dmitry
>
> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Little Scott-B11206
> Sent: Wednesday, May 25, 2011 15:26
> To: 'sv-ac@eda-stds.org'
> Subject: [sv-ac] Additional feedback on 3213
>
> Hi Dmitry:
>
> I apologize for being slow with this feedback.
>
> In 16.5.1, you say "Here are formal definitions of a sampled value." I
> would prefer something like, "Below is the formal definition of sampled
> value."
> [Korchemny, Dmitry] Done.
>
> I believe logic and #1step should be bold.
> [Korchemny, Dmitry] Made logic bold. #1step is typeset inconsistently
> in the LRM. I In most cases it is not bold. Therefore I leave it as it
> is. I opened new Mantis 3585 for this issue.
>
> I would prefer to remove the paragraph "In the LRM several types of
> sampling...". I don't really believe that the term sampling is used
> inconsistently. I believe it is an issue with the term sampled value
> for which we now provide a formal definition. My problem is that we
> now define sampled value to mean the current value for certain variable
> types. That obviously isn't a sampled value by the intuitive
> definition of sampled value. Given this definition of sampled value,
> you are forced to talk about when you sample the sampled value.
> Although you have avoiding that phrase by saying thing like a sampled
> value is "taken" in the Postponed region or a function returns the
> sampled value from the Postponed region. I would prefer to see you
> define another term concurrent sampled value or something that doesn't
> have meaning elsewhere in the LRM. I have obviously been outvoted on
> that direction, so I will drop this objection.
> [Korchemny, Dmitry] I removed the paragraph. I still think that the
> notion of sampling is not completely consistent in the LRM: we have
> sampling is assertions, in covergroups, etc. Their sampling is done in
> different regions, and the terminology becomes confusing. The term
> "sampled" should be applicable in our case. For example, we can say
> that the function $past samples its argument at the previous clock
> tick; if its argument is a design variable, it samples it in the
> Preponed region, in other cases it samples it in the Postponed region.
> It would be more accurate to say that there are different rules for
> sampling constituents of its expression. However, I would avoid such an
> explanation in the LRM in order not to repeat the definition of sampled
> value separately for sampled value functions.

[SL]: I would MUCH prefer this explanation. I think this makes sense and doesn't convolute my intuitive notion of sampling. It is much less confusing than the current definition which is: "$past returns the sampled value of expression1 from the Postponed region of a particular time step strictly prior to the one in which $past is evaluated." I believe that the common case is design variables which are sampled in the Preponed region. At first glance, this $past definition seems to be saying that I will get the sampled value from the Postponed region. When I read it more carefully I realize that it is saying that the sampled value is sampled (or taken as you seem to prefer) in the Postponed region. The sampled value of a design variable doesn't change during the simulation cycle, so what $past returns in the sampled value of the design variable from the Preponed region of the previous clock tick. Wouldn't it be more clear to say: "$past samples its argument at the previous clock tick; if its argument is
 a design variable, it samples it in the Preponed region, in other cases it samples it in the Postponed region." That sentence tells me that design variables get sampled in the Preponed region and everyone else gets sampled in the Postponed region for the sampled value functions. Why is that less clear...particularly for the common case of design variables?

> Thanks,
> Scott
>
> ---------------------------------------------------------------------
> 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, and is
believed to be clean.