RE: [sv-ac] Polling 196 items

Hillel,
 
Thx for the detailed write-up, it's always better to have something concrete
to discuss. Here's a quick rundown of the list, and my opinions/concerns.
 
1. Some form of data types is required for property/sequence formal
parameters.
 
    - SV is a strongly typed language. Strongly type language has its
advantages.
 
BT: Yes indeed. But I think we should also have qualifiers i.e.
Boolean/Sequence kind to relieve the issues in 2 (below).
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.
 
BT: Yes and with qualifiers possibly we can accomodate inconsistency and
maintain backward compatible too (either all qualifier+type or nothing).
This also answers item 7.
 
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.
 
BT: No, deal with it in the future. Input/output is confusing. Currently
everything is input. Need to have a "attempt-global variables" (across all
attempts) first before "exporting" is considered.
 
4-6 below: No. I think this is too radical change needs more serious
consideration. In essence, the "value"/"ref" do not make much sense because
@(... clk) can occur all over. The terminology does not have much meaning
currently for example after I sample a value at the "clk event" it is passed
by value (or reference it's same) to anything else ... With this proposal in
some cases (e.g. the value examples below) I might have pass by value and an
@(...) inside meaning I am testing the same thing over and over and over
again ... this is not user friendly to say the least. I think with the short
amount of time making this usable and user friendly is not possible. The
properties already have a unique sampling mechanism (not like functions they
can sense time, and not like tasks they cannot block).
 
So in summary I think we can try to tackle type (time-permitting), that has
the most return for the effort: compile-time flagging of issues. As far as
ref/value as I said it does not make much sense with the current varied
"activation" (from below) locations it is already *implicit* in where you
put activation so if we do implement it we have to revise the clocking as
well. This can only lead to large complexity and user distaste if we start
restricting/adding new interpretations to things.
 
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:
 

--
Dr. Bassam Tabbara
Architect, R&D
Novas Software, Inc.
(408) 467-7893
 
  _____  
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Miller
Hillel-R53776
Sent: Friday, November 19, 2004 2:05 AM
To: sv-ac@eda.org
Cc: Miller Hillel-R53776
Subject: [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.