RE: [sv-ac] P1800 issues - STU2

Adam,

I am not sure how declaring befoe use will help the problem with the
function, because the user may do this even if declared before.

My point was that the asssertions are slightly different, they always sample
the signals, and the user may want to put them in different places in the
design. However, I agree that it can be done also with declarations up in
front.

edd
 

> -----Original Message-----
> From: Adam Krolnik [mailto:krolnik@lsil.com] 
> Sent: Friday, April 08, 2005 1:59 PM
> To: Eduard Cerny
> Cc: 'Kulshrestha, Manisha'; sv-ac@eda.org
> Subject: 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"
>