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 08:30:50 2004
This archive was generated by hypermail 2.1.8 : Mon Nov 22 2004 - 08:30:58 PST