Re: [sv-ac] 928 Proposal Updated

Hillel,

Function templates (a.k.a., parameterized functions) were requested of
SV-BC during the P1800 balloting, but they were very controversial --
and understandably so, because it took many years for C++ to get
function templates right.

See http://www.eda-stds.org/svdb/bug_view_page.php?bug_id=696 and also
http://www.eda-stds.org/sv-bc/hm , searching for "ballot issue 225".

In the meantime, a workaround within the bounds of the existing LRM is
to use classes.  For example,

   class C#(type T);
     function T reverse(T a);
       for ( int i = $low(a), j = $high(a); i <= $high(a); i++, j--)
         reverse[i] = a[j];
     endfunction:reverse
   endclass:C

could be called as C#(type(expr))::reverse(expr).  This could be
prettied up with a macro `reverse(expr)

  `define reverse(expr) C#(type(expr))::reverse(expr)

-- Brad

-----Original Message-----
From: Miller Hillel-R53776 [mailto:r53776@freescale.com] 
Sent: Friday, June 30, 2006 6:29 AM
To: Eduard Cerny; Korchemny, Dmitry; Adam Krolnik; Lisa Piper
Cc: Bassam Tabbara; Havlicek John-r8aaau; Brad.Pierce@synopsys.COM;
sv-ac@eda-stds.org
Subject: RE: [sv-ac] 928 Proposal Updated

There needs to be a consistency between property/sequences and
task/functions. Task/Functions that are called from properties/sequences
need to be equally parameterizable as their callers.  I am not sure that
parameterized classes give you this and how this can be used with
assertions. 

I could not find any examples in the LRM that show how calling
tasks/functions with parameters is done. Is this supported?

Thanks
Hillel


-----Original Message-----
From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] 
Sent: Friday, June 30, 2006 4:16 PM
To: Miller Hillel-R53776; Eduard Cerny; Korchemny, Dmitry; Adam Krolnik;
Lisa Piper
Cc: Bassam Tabbara; Havlicek John-r8aaau; Brad.Pierce@synopsys.com;
sv-ac@eda-stds.org
Subject: RE: [sv-ac] 928 Proposal Updated

Yes... that would be nice. As Brad pointed out it can be done through
parameterized classes but that does not help assertions.

ed
 

> -----Original Message-----
> From: Miller Hillel-R53776 [mailto:r53776@freescale.com]
> Sent: Friday, June 30, 2006 9:02 AM
> To: Eduard Cerny; Korchemny, Dmitry; Adam Krolnik; Lisa Piper
> Cc: Bassam Tabbara; Havlicek John-r8aaau; Brad.Pierce@synopsys.COM; 
> sv-ac@eda-stds.org
> Subject: RE: [sv-ac] 928 Proposal Updated
> 
> Ed,
> 
> If we add #(parameters) to sequences and properties we will most 
> probably will need the same for tasks and functions.
> 
> Thanks
> Hillel
> 
> 
> -----Original Message-----
> From: owner-sv-ac@eda-stds.org [mailto:owner-sv-ac@eda-stds.org] On 
> Behalf Of Eduard Cerny
> Sent: Friday, June 30, 2006 3:53 PM
> To: Korchemny, Dmitry; Adam Krolnik; Lisa Piper
> Cc: Bassam Tabbara; Havlicek John-r8aaau; Eduard.Cerny@synopsys.com; 
> Brad.Pierce@synopsys.com; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] 928 Proposal Updated
> 
> I agree with Dmitry, we do need untyped argumenst, unless we introduce

> parameterized properties, i.e., someything like #(parameters) (args) 
> forms.
> And even then ...
> The typed arguments were introduced initially to deal with recusrive 
> properties and I think that this is where it will be used most.
> 
> ed
>  
> 
> > -----Original Message-----
> > From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> > Sent: Thursday, June 29, 2006 5:48 PM
> > To: Adam Krolnik; Lisa Piper
> > Cc: Bassam Tabbara; john.havlicek@freescale.com; 
> > Eduard.Cerny@synopsys.COM; Brad.Pierce@synopsys.COM; 
> > sv-ac@eda-stds.org
> > Subject: RE: [sv-ac] 928 Proposal Updated
> > 
> > Hi Adam,
> > 
> > I think that the requirement to keep all arguments typed if
> at least
> > one of them is typed is too strong. Consider the following example:
> > 
> > property p(bit en, a, b, c, int n);
> > 	en |=> ({a, b} == c) [*n];
> > endproperty
> > 
> > You cannot make a and b typed without loss of generality - you will 
> > have to declare a separate property for each length combination.
> > 
> > Thanks,
> > Dmitry
> > 
> > -----Original Message-----
> > From: owner-sv-ac@server.eda-stds.org 
> > [mailto:owner-sv-ac@server.eda-stds.org] On Behalf Of Adam Krolnik
> > Sent: Tuesday, June 27, 2006 10:17 PM
> > To: Lisa Piper
> > Cc: Bassam Tabbara; john.havlicek@freescale.com; 
> > Eduard.Cerny@synopsys.com; Korchemny, Dmitry; 
> > Brad.Pierce@synopsys.com; sv-ac@server.eda-stds.org
> > Subject: Re: [sv-ac] 928 Proposal Updated
> > 
> > 
> > 
> > Hello Lisa;
> > 
> > You did not include events in your list of necessary types - for 
> > passing in clocks, or resets, or other.
> > 
> > If one can specify a type for the argument, is it necessary
> to allow
> > for a void type?
> > If the new types are going to be added, I would like to see the 
> > supported two ways to specify the interface for the property or
> > sequence:
> > 
> > 1. All untyped
> > 2. All typed
> > 
> > If you've gone to the trouble of giving some arguments
> types (for the
> > purposes of helping ensure they are using them correctly) then you 
> > will give all the arguments a type.
> > 
> > Alternatively, one may not care about the type and mostly use 
> > arguments for signals, numbers, etc.
> > 
> > Lastly, is 'const' a type modifier? Is there an implicit type 
> > associated with it?
> > I would expect that users would use 'int' or 'logic' instead of 
> > reaching for const initially. What about '$' for infinite
> value - it
> > would have to be accepted under 'const'.
> > 
> >     Thanks.
> > 
> > -- 
> >      Soli Deo Gloria
> >      Adam Krolnik
> >      ZSP Verification Mgr.
> >      LSI Logic Corp.
> >      Plano TX. 75074
> >      Co-author "Assertion-Based Design"
> > 
> 
>