[sv-ac] RE: deferred assertion question

I believe such a restriction is a bit too draconian, especially when the function call is pure and has none of these problems.

In addition to the issues mentioned by Steven, I see other problems with delaying function calls in the arguments. For example, the arguments may be automatic variables that are no longer available at the point of the call, or there may be no function call at all, just an index select in which either the index or memory context changes.

I think that the best way to solve this is to require immediate evaluation of the function call (when the assertion expression is evaluated). The requirement would then be to evaluate and store the arguments to the "single subroutine call" until the delayed function executes. This would provide consistent results regardless of the arguments (dynamic variables, automatic variables, indexed expressions, and function calls).

                Arturo

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Seligman, Erik
Sent: Friday, February 11, 2011 7:39 AM
To: Steven Sharp; sv-ac@eda.org
Subject: [sv-ac] RE: deferred assertion question

I think the 'single subroutine call' restriction was put in place in part due to issues like this: as I interpret the text, the foo() call would count as a second subroutine, and thus be illegal.

Do others have a different opinion?

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Steven Sharp
Sent: Thursday, February 10, 2011 5:18 PM
To: sv-ac@eda.org
Cc: Steven Sharp
Subject: [sv-ac] deferred assertion question

Clause 16.4 on deferred assertions specifies that their action blocks can only consist of a single subroutine call. It says that the actual argument expressions for input arguments are evaluated with the values of the variables at the time the assertion expression is evaluated, not the values when the subroutine is called. But it is unclear whether this means the actual argument expressions should be evaluated at the time the assertion expression is evaluated, or whether the argument expressions should be evaluated at the time the task is called, but using variable values from the time that the assertion expression is evaluated.

In most cases, there is no difference between these two. But if the actual argument expression contains function calls, then it could matter. For example:

    assert #0 (bad) else my_task(foo(v));

If the argument is evaluated when the assertion expression was evaluated, then foo() will be called when the assertion expression is evaluated. Any side effects will happen immediately, and any outside variables it reads will use their immediate values. If the argument is evaluated in the Reactive region, then any side effects will happen in the Reactive region, and any outside variables it reads will use their values from the Reactive region.

It is simpler if the actual arguments are evaluated immediately. But the text only says that the immediate values of the variables are used in the evaluation, without saying when that evaluation takes place. I assume that this was just an attempt to explain why it might matter that the evaluation is done immediately: because the variable values might change. Note that taking this text literally would cause problems if the evaluation is done later, since it doesn't say that evaluation uses the immediate value of nets, only variables.

Another literal interpretation would be that function calls aren't allowed, since the text says that the action block shall consist of a single subroutine call. If there is a function call in the argument, that would be a second subroutine call. But I assume that the intent was to say that there could only be a single *task* call statement, but since that could actually be to a void function, the generic term "subroutine" was used. I don't think it was intended to disallow ordinary function calls in the argument expressions.

Can someone clarify the intent? Or if this case was never considered, can you provide arguments for a particular interpretation?

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