RE: [sv-ac] IEEE 1800 SV-AC - minutes of meeting on 10/03/2006

I recommend that we attempt to fully align with the way parameters are
handled with SystemVerilog tasks. This will assist us from trying to
re-invent the wheel and avoid us from becoming a different language
within a language. I believe we can work out the backward compatibility
issues. Endless effort was invested to give SVA a Verilog look and feel,
the same should be done with parameters.

Things like meta-language/conversion is something that should involve
all commitees. 
For example, 
- If passing sequence/property as a parameter is something required then
why should passing a task as a parameter not be required. There are
libraries that involve tasks as well.
- If avoiding conversion is required for performance issues then why
should it not be required when passing a task parameter.
- If tasks have default arguments then propertys should have default
arguments.

I believe that this will assist us when moving forward with Dmitry's
stuff as well. We do not want to put time in to invent a dmitry solution
for properties and then to re-invent a completely different solution for
tasks.

Hillel


-----Original Message-----
From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
Sent: Thursday, October 05, 2006 7:57 PM
To: Miller Hillel-R53776; Eduard Cerny
Cc: sv-ac@eda-stds.org
Subject: RE: [sv-ac] IEEE 1800 SV-AC - minutes of meeting on 10/03/2006

Hi Hillel,

I don't feel quite comfortable with the parameter passing mechanism. We
identified three of them:

- by value,
- by reference, and
- by substitution 

For sequences and properties none of them fits exactly: it is not clear
to me what passing by value and by reference is in their context.
Passing sequences and properties by substitution is rather natural,
excluding two cases:

1. The definition of local variables does not fall strictly speaking
into this category:

sequence s1;
	local bit r;
	(b, r = b) ##1 r;
endsequence

sequence s2(sequence s);
	a ##1 s;
endsequence

Invocation: s2(s1).

2. Recursive property cannot be passed by substitution.

As for passing bit vectors, they may be passed both by reference and by
value. But sometimes you want to pass untyped arguments in order to
avoid a redundant conversion from 2-value to 4-value or vice versa. In
this case we face a problem of bit selection which works
non-intuitively.

Therefore I think we should formally define what the parameter passing
in sequences/properties actually is. Only then we'll be able to
elaborate syntactic subtleties. It might be a right thing to impose
first reasonable limitations on the arguments to get a straightforward
definition; this will allow us time to come with a clean complete
solution. Otherwise we risk sticking here for a long time.

I agree with you about not passing property instantiation as a
parameter. E.g.,

property p(sequence s(a, b), ...);

I believe that in Faisal's example passing of a sequence expression is
enough.

property p(sequence s, ...);

If you are talking about generic properties, say something like:

property p(s, bit x, y);
	s(x) |=> s(y);
endproperty;

we should just allow passing sequence names as parameters (= higher
order meta-functions).

It is a gray area of LRM, and one could claim that it is already allowed
(though I doubt that anybody has implemented it).

Will it solve the problem?

The type of s should be (implicit->sequence) - a sequence taking an
untyped argument and returning a sequence expression (according to
functional notation). One could invent more SV-friendly syntax for the
type:

sequence(implicit).

I.e., the complete declaration would look like:

property p(sequence(implicit) s, bit x, y);
	s(x) |=> s(y);
endproperty;

I am just wondering whether we want to introduce this enhancement of the
type system, at least in the near future.

Regards,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Miller Hillel-R53776
Sent: Wednesday, October 04, 2006 7:48 AM
To: Eduard Cerny
Cc: sv-ac@server.eda-stds.org; Miller Hillel-R53776
Subject: RE: [sv-ac] IEEE 1800 SV-AC - minutes of meeting on 10/03/2006

Ed I attended todays meeting. 

Some comments:
- Adding the explicit pass by reference, with keyword 'ref''  does not
hurt backward compatibility. 
- To maintain backward compatibilty for pass by value I propose adding a
keyword to the SV language that would explicity declare a formal
argument to be assigned using (pbv) pass by value (e.g. pbv var1).
- ref is different to substituation in a couple of ways
-- type checking. I think only the number of bits need to be the same. I
am not sure this is real type checking.
-- bit selection cannot always be done on a substituted variable and may
give different results to pass by reference.
   For example:

   sequence a(a1)
      a1[1] ##1 a2;
   endsequence

   in substitution the instantiation

   a(e1 && e2) 

  is different to

   a(e1 && e2) when passing by reference.
- I recommend not expanding the capabilities of passing sequences and
properties and to stop from encouraging it. We most probably can get
equivalent capabilities with Dimitry's proposals later on (Dimitry
please comment). This approach is not natural at the functional level
and it does not meet the essence of the SystemVerilog language. For
example a task cannot have a task activation as a actual parameter. 


   

Hillel Miller


-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Eduard Cerny
Sent: Tuesday, October 03, 2006 8:06 PM
To: sv-ac@eda.org
Subject: [sv-ac] IEEE 1800 SV-AC - minutes of meeting on 10/03/2006

Please find attached the minutes of today's meeting. Let me know if
corrections are required.

ed