RE: [sv-ac] Call to vote: Due May 2

Hi Tom,

Unfortunately this proposal cannot be done that simple. For example, checker inputs (I am talking about the current state) "sampled" values of input checker variables are used not only in concurrent assertions, but in checker NBA as well. Even in concurrent assertions checker inputs are not always sampled, consider the following example:

check mycheck(a && seq.triggered, ...);

checker check(b, ...);
        assert property (...b...);
endchecker

Is b sampled here or not?

What about sentences such as

- The sampled values are used to evaluate value change expressions or Boolean subexpressions that are required to determine a match of a sequence.
- The current value of the variable is used in the clock expression, while the sampled value of the variable is used within the assertion.
- etc

which are simply wrong (or inaccurate)?

Addressing each and every case you will end up with something very similar to my proposal.

I implemented the first alternative you are suggesting below in the current version of my proposal, but several people find it problematic. I would modify your second alternative by introducing a new function $concurrent and saying that $sampled returns the same thing and is kept for backward compatibility reasons (a milder form of deprecation). Keeping $sampled in its current form and introducing $concurrent in addition to it is problematic, as we will end up with something like:

$concurrent returns sampled values for design variables, and current values for automatic variables, local variables, etc.
$sampled returns sampled values for design variables. It shall be illegal to call it on automatic variables, local variables, etc.

Thanks,
Dmitry

-----Original Message-----
From: Thomas J Thatcher [mailto:thomas.thatcher@oracle.com]
Sent: Saturday, April 30, 2011 00:20
To: Korchemny, Dmitry
Cc: 'sv-ac@eda-stds.org'
Subject: Re: [sv-ac] Call to vote: Due May 2

>
> Mantis 3213 ____ Yes __x__ No
>
> http://www.verilog.org/mantis/view.php?id=3213
>
> http://www.eda-stds.org/mantis/file_download.php?file_id=4961&type=bug
> <http://www.eda-stds.org/mantis/file_download.php?file_id=4961&type=bug>
>
>
>

Why not simplify this proposal? Instead of defining the new concept of
"concurrent context", and doing a global substitute of "sampled value",
why not just state the concept as follows:

1. The sampled value of a variable is the value that was sampled in
     the preponed region. (No change from current LRM)
2. Variables used in concurrent assertions are evaluated as follows:
     1. Static variables use the sampled value
     2. Automatic variables use the current value
     3. Sequence methods such as triggered() use the current value
     4. Checker inputs use the sampled value.
     4. Free checker variables use the current value.

This definition would give all the functionality you want, but the LRM
would not be making absurd statements like, "The sampled value of a free
  checker variable is the current value"

Then, we can do one of the following:

Either change the definition of the $sampled function so that it returns
the value of its expression argument evaluated according to the rules in
sec 16.x.y

OR

Keep the definition of $sampled the same and introduce a new function
which does evaluate according to the above rules.

The resulting proposal would be much simpler, there would be less change
to the LRM, and I think much more understandable.

Tom
---------------------------------------------------------------------
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.