Re: [sv-ac] P1800 issues - STU2

Hello all;

This example code fragment of an impure function (one that references a signal
that does not come from its interface - the set of inputs) is an interesting case.

This is a common error to make - converting code into a function, or extending a 
function with additional signals and forgetting to put all the signals into the
interface.

[Note that writing such a function may result in simulation errors because the
code is not sensitive to changes of that function. This is fixed if one is using
the function inside an always_comb statement. However there still may exist a problem
for assign statements making calls to the function.]

Define before usage rules can help a user to discover these problems.
These same problems can occur when creating properties and sequences. Forgetting
to put a signal into an interface, or creating a property or sequence that uses
a signal before it is defined can suggest a possible problem that needs to be reviewed.
Similarly for the assertion statements, passing signals to a propert or sequence or 
writing an inline property would benefit from the signals existing and not accidently
being typed wrong and ending up with an implicit signal being created.

At worst, one needs to move the declaration of a signal above the code that will
use it. It may even suggest to the user that they explain what the signal is, for the
benefit of the reader.

I would recommand that we follow the existing rules for use vs. definition and not 
create new special rules for these constructs.


module A;
 > function integer abc(input i);
 > begin
 > if (a)        // Signal "a" is impure, obtaining its value from the module scope.
 >   abc = 1;
 > else
 >   abc = 0;
 > end
 > endfunction
 >
 >
-- 
     Adam Krolnik
     ZSP Verification Mgr.
     LSI Logic Corp.
     Plano TX. 75074
     Co-author "Assertion-Based Design"