RE: [sv-ac] P1800 issues - STU2

SV-AC,

I agree with Adam on this.

Let's stay with enforcing declaration of module items
before use in task and function declarations.  That way
there is only one rule to explain and implement for the
various scopes that can be declared inside module scope.

Ballot item #202 is a step in the direction of Ed's concern:

  http://www.eda-twiki.org/svdb/bug_view_page.php?bug_id=0000627

Instantiations introduce by bind statements are placed at
the end of the target scope.  That means all declarations in
the target scope will be visible to the bound instantiation
and all its actuals.

Regards,
Doug Warmke

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of Eduard Cerny
> Sent: Sunday, April 10, 2005 11:41 AM
> To: 'Adam Krolnik'; 'Eduard Cerny'
> Cc: Kulshrestha, Manisha; sv-ac@eda.org
> Subject: 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"
> > 
> 
> 
>