RE: [sv-ac] Final proposal for 196

Manisha,

I was reffering to the feature below (LRM 3.1a page 240). This is supported for untyped parameters. I does not exist in the proposal for typed features.

In the poll it lost by a majority.

Thanks

Hillel

To access a local variable of a subsequence, a local variable must be declared and passed to the instantiated

subsequence through an argument. An example below illustrates this usage.

sequence sub_seq2(lv);

a ##1 !a, lv = data_in ##1 !b[*0:$] ##1 b && (data_out == lv);

endsequence

sequence seq2;

int v1;

c ##1 sub_seq2(v1) ##1 (do1 == v1); // v1 is now bound to lv

endsequence

Local variables can be passed into an instance of a named sequence to which ended is applied and accessed in

a similar manner. For example

sequence seq2a;

int v1; c ##1 sub_seq2(v1).ended ##1 (do1 == v1); // v1 is now bound to lv

endsequence

-----Original Message-----
From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentorg.com]
Sent: Monday, November 22, 2004 6:30 PM
To: Eduard.Cerny@synopsys.com; Miller Hillel-R53776; sv-ac@eda.org
Subject: RE: [sv-ac] Final proposal for 196

Hi Hillel,
 
I am not sure what you mean by "Exporting local variables thru typed parameters is not supported.".
Are you saying that local variables can not be passed using typed arguments. If yes, then what is
the motivation for this restriction ? Or may be it means something else.
 
Thanks.
Manisha

  _____

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Eduard Cerny
Sent: Monday, November 22, 2004 8:08 AM
To: 'Miller Hillel-R53776'; sv-ac@eda.org
Subject: 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 09:04:09 2004