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

From: Korchemny, Dmitry <dmitry.korchemny_at_.....>
Date: Thu Oct 05 2006 - 10:56:53 PDT
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
Received on Thu Oct 5 10:57:30 2006

This archive was generated by hypermail 2.1.8 : Thu Oct 05 2006 - 10:57:47 PDT