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. edReceived 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