RE: [sv-ac] Final proposal for 196

Hi Hillel,
 
A few comments:
 
- Currently, string data type is not allowed in assertions because it is a
dynamic datatype. Do you wish to keep it in the proposal? It would affect
other parts of the LRM.
 
- You indicate that default parameters are not supported, but that goes
against the current LRM in which default values are supported. Or does that
apply only to the typed parameters?
 
- In Documentation, you say "All SV data type are supported." Do you include
classes, strings, dynamic arrays, mailboxes, etc.? That might require
examining more closely how they are sampled etc. and I am not sure that we
have time for that.
 
Best regards,
 
ed
 

  _____

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Miller
Hillel-R53776
Sent: Sunday, November 21, 2004 10:01 AM
To: Miller Hillel-R53776; 'sv-ac@eda.org'
Subject: [sv-ac] Final proposal for 196

Proposal for adding datatypes to formal parameters of assertion sequences
and properties
 

Motivation
----------
1. To be aligned with the overall System Verilog data typing definitions.
System Verilog is
   a strongly typed language.
2. To allow strongly typed code to provide better compiler/tool
compabilities, optimization and
   error detection.
3. To extend the data types that can be passed to assertions. One may pass
an class object
   and activate a method of that class.
4. To allow activations of properties thru the DPI, with correct data types.
5. To allow a well defined interface to properties such that external users
do
   not pass arguments that provide undesirable behavior.
 
Syntax Changes
--------------
 
Note: The following changes make usage of already defined BNF for
'tf_port_list' and 'list_of_arguments'.
 
We simplify tf_port_list for the sake of explanation of what parts we steal
and what
we do not steal from the existing syntax in order to add the optional data
types.
No changes in the tf_port_list BNF is required.
 

tf_port_list ::=
  tf_port_item { , tf_port_item }
 
tf_port_item ::=
  [data_type] port_identifier variable_dimension [ = expression ] ;
 
 
 
data_type ::=
integer_vector_type [ signing ] { packed_dimension }
| integer_atom_type [ signing ]
| struct_union [ packed [ signing ] ] { struct_union_member {
struct_union_member } }
{ packed_dimension }
| enum [ enum_base_type ] { enum_name_declaration { , enum_name_declaration
} }
| string
| type_identifier { packed_dimension }
 

What is supported?
------------------
1. pass by reference as default - a typed formal parameter which is a pass
by reference parameter, will get the value of the
respective evaluation of the actual parameter at the time the formal
parameter is referenced. This is what is supported
today with untyped types.
2. Backward compatibility with the current formal parameter definition.
Allowing untyped formal parameters.
 
What is not supported?
----------------------
1. Writing from within a property/sequence to formal parameters with
datatypes.
2. input/output/inout direction to parameters with datatypes.
3. 'pass by value' formal parameters.
4. Default parameters.
5. Declaring a list of formal parameters with a specific type. Each formal
parameter will require a prefix
   which specifies its declared data type. Any formal parameter that is not
prefixed by a type will be untyped no
   matter where appears in the port list.
 
(1) Property declaration
 
Change:
 
property_declaration ::=
  property property_identifier [ ( [ list_of_formals ] ) ] ;
  { assertion_variable_declaration }
  property_spec ;
endproperty [ : property_identifier ]
 
To:
 
property_declaration ::=
  property property_identifier [ ( [ tf_port_list ] ) ] ;
  { assertion_variable_declaration }
  property_spec ;
endproperty [ : property_identifier ]
 
(2) Property instance
 
Change:
 
property_instance ::=
ps_property_identifier [ ( [ actual_arg_list ] ) ]
 
To:
 
property_instance ::=
ps_property_identifier [ ( [ list_of_arguments ] ) ]
 
(3) Sequence declaration
 
Change:
 
sequence sequence_identifier [ ( [ list_of_formals ] ) ] ;
{ assertion_variable_declaration }
sequence_expr ;
endsequence [ : sequence_identifier ]
 
To:
 
sequence sequence_identifier [ ( [ tf_port_list ] ) ] ;
{ assertion_variable_declaration }
sequence_expr ;
endsequence [ : sequence_identifier ]
 
(4) Sequence instance
 
Change:
 
sequence_instance ::=
ps_sequence_identifier [ ( [ actual_arg_list ] ) ]
 
To:
 

sequence_instance ::=
ps_sequence_identifier [ ( [ list_of_arguments ] ) ]
 
Documentation:
 
Formal parameters of properties and sequences can optionally be typed. All
SystemVerilog data types are supported. To
declare a type for a formal parameter of a property or sequence it is
required to prefix the parameter with a type. A formal
parameter which is not prefixed by a type will be untyped. See above for the
definition of untyped variables.
 
Exporting local variables thru typed parameters is not supported.
 

Examples:
 
1. Two equivalent ways of passing parameters, the first has untyped
parameters and the second has typed parameters:
 
property rule6_with_no_type(x, y);
##1 x |-> ##[2:10] y;
endproperty
 
property rule6_with_type(bit x, bit y);
##1 x |-> ##[2:10] y;
endproperty
 
2. Example where a local variable is used to sample a formal parameter, in
order to get the effect of
   pass by value. This is needed because currently pass-by-value is not
supported.
 
sequence foo(bit a, bit b);
bit loc_a;
(1'b1, loc_a = a) ##0
(t == loc_a)*[0:$] ##1 b
endsequence
 
Received on Mon Nov 22 08:07:25 2004