Re: [sv-ac] AC 196:

John,
For compatibility to existing style, I am of the following opinions:
1. Adding a type is only for type checking and nothing else, so as to ensure proper matching when comparing one object against another.
2. Formal arguments are by reference, as currently done.
3. If a user needs to initialize the value of a local variable to a formal argument, this can be done at declaration.
Thus,
  property P (logic a, int b, int c);
    int v = b;
     @ (posedge clk) (a, v==v+1) |=> c==v;
  endproperty : P
Am I missing something here?
Ben

In a message dated 11/17/2004 10:01:50 PM Eastern Standard Time, John Havlicek <john.havlicek@freescale.com> writes:

>Adam:
>
>I sent a mail before reading yours trying to explain that
>passing by value to a sequence or property should be
>equivalent to assigning to a local variable in the
>sequence or property declaration.
>
>This is exactly how we defined the semantics of pass-by-value
>in the ECBV proposal to Accellera in 2002. In ECBV, however,
>pass-by-reference was the default. Pass-by-value required
>a modifier.
>
>In the current context, I think that pass-by-value to
>sequences and properties is a useful abbreviation, but I also
>think that having the default passing mechanism be
>by value, rather than be reference, is not so nice.
>I appreciate your comments about building "gotcha"s into
>the language.
>
>Do you think that the inconvenience of specifying reference
>arguments explicitly outweighs the convenience of being
>able to have value arguments?
>
>Best regards,
>
>John H.
>
>> X-Authentication-Warning: server.eda.org: majordom set sender to owner-sv-ac@eda.org using -f
>> Date: Wed, 17 Nov 2004 10:09:35 -0600
>> From: Adam Krolnik<krolnik@lsil.com>
>> X-Accept-Language: en-us, en
>> Cc: <sv-ac@eda.org>
>> X-Scanned-By: MIMEDefang 2.39
>> X-Virus-Status: Clean
>> X-Virus-Status: Clean
>> Sender: owner-sv-ac@eda.org
>>
>>
>>
>> HI Hillel;
>>
>>
>> >Your examples are correct.
>> (Re-showing the examples)
>>
>> SV-AC - these are equivalent in this proposal ... not the other way around !!
>>
>> property rule6_with_no_type(x, y);
>> ##1 x |-> ##[2:10] y;
>> endproperty
>>
>> property rule6_with_type(ref bit x, ref bit y);
>> ##1 x |-> ##[2:10] y;
>> endproperty
>>
>>
>> >I prefer the form of a task because you have a definition of 'pass by value' and 'pass
>> >by reference'. I believe that both of these are needed.
>>
>> It would be good to provide justification, with examples, why both forms are necessary.
>> I believe that through the use of local variables one could obtain
>> the effect of pass by value only. E.g.
>>
>> reg val1, val2;
>>
>> ... (val1 = parameter_a, val2 = parameter_b, property_rule6(val1, val2)) ...
>>
>> By capturing a value in a local parameter, we call the property and give it the
>> stored values.
>>
>> I see users being confused and asking why 'ref' must be specified for all parameters.
>> Consider the user error of forgetting 'ref' and the user's confusion with his assertion
>> failing to detect errors because it only has the values from one point in time. This
>> feature is definitely at the level of *gotcha*, though it may be more powerful for
>> expert users in other ways. We need to take care that assertions don't become too
>> complex to easily use.
>>
>> As a counter idea, I believe that through the use of local variables one could obtain
>> the effect of pass by value only. E.g.
>>
>>
>> If the pass by value capability remains, it will be necessary to explain that the
>> sequence/property model is that of a task call, not a module instantiation. Note that
>> the original proposed model by Synopsys was to inline assertions - a replacement of the
>> formal arguments with the actual arguments passed. There was no though of pass by value
>> or reference.
>>
>> Lastly, this change of intellectual model does not match the existing models of OVA, OVL
>> and proprietary tools present in many leading organizations.
>>
>> Thanks.
>>
>> Adam Krolnik
>> Verification Mgr.
>> LSI Logic Corp.
>> Plano TX. 75074
>> Co-author "Assertion-Based Design"
>>
>>
>>
>>
>>
>

-- 
-- 
-----------------------------------------------------------------------------
Ben Cohen Trainer, Consultant, Publisher (310) 721-4830 
http://www.vhdlcohen.com/ vhdlcohen@aol.com 
Author of following textbooks: 
* Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004 isbn 0-9705394-6-0
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8 
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------