[sv-ac] Polling 196 items

Hi,
 
I would like to poll in order to get the general feeling in order to make the final 196 proposal. Please give me
a yes/no answer for each of the items. I will go according to the majority (anyone that gets this email can answer
the poll).
I will try add some pro/con summary for each decision that I collected so far.
In addition below are examples that may help understand the different wordings.
 
 
1. Some form of data types is required for property/sequence formal parameters.
    pros:
       - SV is a strongly typed language. Strongly type language has its advantages.
 
2. Backward compatibility needs to be maintained.
    pros:
       - Existing code will run.
       - We can deal with adding a datatypes for sequence and property parameters later.
    cons:
       - A solution for differing between non-typed and typed parameters is required.
       - Additional education will be required when learning the language.
       - We cannot use the default one bit type when no data type is declared. This is
         not consistent with SV.
 
3. Add formal parameter direction in this proposal.
    pros:
       - will able to handle exporting a local variable thru a typed formal argument.
    cons
       - can deal with this in the future.
       - this is orthogonal to the data type proposal and should come in a different proposal.
 
4. Need to support pass by value.
   pros:
       - System Verilog tasks support pass by value we would be aligned with the language. In Rome behave like Romans.
       - System Verilog tasks support multiple-threading for monitors. Once a designer is familiar with these multiple-threading monitor
         tasks, getting him to move to properties (for multi-threading monitors) will become easier because he/she will
         have the same look and feel.
   cons:
       - Pass by value can be achieved by sampling a local variable before/after activating a sequence/property.
       - There is no relationship between SV tasks and properties/sequences.
 
5. Need to support pass by reference:
    pros:
       - Already supported with the current proposal.
 
6. Pass by reference needs to be prefixed with the 'ref' keyword.
    pros:
       - In SV tasks 'pass by reference' formal parameters required the 'ref' keyword. In Rome behave like Romans.
       - System Verilog tasks support multiple-threading for monitors. Once a designer is familiar with these types
         of tasks getting him to move to properties (for multi-threading monitors) will become easier because he/she will
         have the same look and feel. I see property/sequence activation (see below) as a dynamic form, just like SV task activation.
       - If we decide not to support this today, this will become irreversible. It then would be very difficult to align
         to SV tasks.
    cons:
       - We can always add support for 'pass by value' by adding a keyword for 'pass by value' where 'pass by reference' is
          the default.
       - There is no relationship between SV tasks and properties/sequences.
 
7. Untyped formal parameters (as exists today) need to appear in the beginning of the formal parameter list.
    pros:
        - Will allow us to differentiate between typed and untyped parameters.
        - Will allow us to use a type declaration (implicit typing) followed by a list of variables.
    cons:
        - Will add complexity to the proposal.
 
Some examples and definitions.
 
PASS BY VALUE
 
sequence foo(bit a, ref bit b); // a is passed by value
(t == a)*[0:$] ##1 b
endsequence
 
be equivalent to:
 
sequence foo(ref bit a, ref bit b);
bit loc_a;
(1'b1, loc_a = a) ##0
(t == loc_a)*[0:$] ##1 b
endsequence
 
and similarly. The signals in the support of an actual argument
passed to the formal value argument of an instance of foo will
be sampled in the preponed region in the timestep of activation
of the instance. However, as evaluation of the instance progresses
in time, there will not be any resampling of these signals. On the
other hand, signals in the support of the actual argument passed to
the formal reference argument of the instance will be resampled in
the preponed region of each timestep (at least at those for which
the clock event governing the instance is true).
 
USAGE OF 'ref' KEYWORD
 
These are the equivalent forms:
 
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
 
These are definitely not the same:
 
property rule6_with_no_type(x, y);
##1 x |-> ##[2:10] y;
endproperty
 
property rule6_wrong_type(bit x, bit y); // With the 'ref' proposal these are 'pass by value' formal parameters.
##1 x |-> ##[2:10] y;
endproperty
 
PROPERTY ACTIVATION
 
You are talking about activation of property instances, not property declarations.
If I write:
 
assert property (@(posedge clk) foo(a,b,c))
 
then the instance foo(a,b,c) gets activated at each posedge of clk.
 
If I write:
 
assert property (@(posedge clk) seqA |-> goo(a,b,c))
 
then, assuming that seqA is singly clocked, the instance goo(a,b,c)
gets activated at each posedge of clk that is an endpoint of seqA.
 
 
Received on Fri Nov 19 02:05:35 2004