RE: [sv-ac] Polling 196 items

Hi Hillel,
 
  Please see my comments below.
 
Thanks,
 
Joseph

________________________________

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.
 
Definitely Yes to leverage the advantage of the typing system.
 
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.
 
Yes
 
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.
 
Not for this proposal, But need to deal with it the sooner the better!!
 
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.
 
Yes
 
5. Need to support pass by reference:
    pros:
       - Already supported with the current proposal.
 
No
 
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.
 
Yes if 4 is allowed
 
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.
 
I really don't like the existence of untyped objects in a strong type
language especially passing parameters to
a called routine. I would rather suggest that at least we need to
provide a type-conversion prefix for untyped
parameters when actual parameter are passing a called routine to make
things more predictable.
 
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 11:25:30 2004