Re: [sv-bc] Partial proposal for issue #091- take #2

Sorry for the resend: hopefully this will not bounce.

If the intention of your footnote is to disallow hierarchical references
infecting
parameter overrides it may fall short. Parameter overrides must be
elaboration
time constants, which is more restrictive. You may end up with an xmr
even if
the expression looks OK, especially because of interfaces. Any parameter
type
override or default must be a constant expression, or for types, a
constant type
expression. I am not sure this is well defined, but excluding xmrs is
definitely
not enough. Again, interfaces are particularly problematic. You may use the
"typeof" some interface's net to override a parameter type on some
instance, but
if that interface was passed to the module through an xmr in the high
conn the
simple test contained herein will not detect the case. Interfaces have
the potential
to cause as many elaboration problems as defparams if we are not careful.

   _Matute

Jacobi, Dan wrote:

> I enhanced the original proposal to capture Shalom's remarks.
> This should prevent the generation of compilation loops and other
> pathological cases.
> The general idea is to prevent the use of hierarchical references (by
> adding a footnote to the BNF)
>
> Following is the enhanced proposal :
>
> This proposal intends to solve the first part of the problem described in
> http://www.eda.org/svdb/bug_view_page.php?bug_id=0000091
> "$typeof function as used in 23.2 is not fully supported in the BNF"
>
> Motivation
> ========
> The example in section 23.2 in the (original) SV 3.1a LRM uses the
> $typeof system function to set the default type of a type parameter:
> / /Example 1:
> / bit [12:0] A_bus, B_bus;
> parameter type bus_t = $typeof(A_bus);/
>
> Also we would like to enable the override of type parameters using the
> $typeof system function such as:
> Example 2:
> /son #( .son_type_param($typeof(A_bus) ) myson (...);/
>
> Section 23.2 also reads:
> "The $typeof system function returns a type derived from its argument.
> _The data type returned by the_
> _$typeof __system function may be used to assign or override a type
> parameter_, or in a comparison with another
> $typeof, evaluated during elaboration."
>
> However the BNF does not enable the usage of the $typeof system
> function to assign a type parameter value as shown in example 1 (Note
> that it does permit the overriding of the type parameters as shown in
> example 2)
>
> The type parameter type declaration BNF reads :
>
> A.2.2.1
> parameter_declaration ::=
> parameter data_type_or_implicit list_of_param_assignments
> | parameter type list_of_type_assignments
> A.2.3
> list_of_type_assignments ::= type_assignment { *,* type_assignment }
> A.2.4
> type_assignment ::= type_identifier *=* data_type
>
> Note that the parameter override as shown in example 2 is enabled
> using the following rules from the BNF
>
> A.4.1.1
> ordered_parameter_assignment ::= param_expression
> named_parameter_assignment ::= *. *parameter_identifier *( *[
> param_expression ] *)*
> A.8.3
> param_expression ::= mintypmax_expression | data_type
> the mintypmax_expression token eventually reduces the system function
> call rule
>
>
> Proposal
> =======
>
> Under section A.2.4
>
> REPLACE
> type_assignment ::= type_identifier *=* data_type
> WITH
> type_assignment ::= type_identifier *=* data_type
> | type_identifier *= **$typeof ( *expression 28 *)*
> | type_identifier *= **$typeof ( *data_type *)*
>
> * Equal signs = parentheses () and the sequences $typeof or all in bold
> ** the number 28 is in supper script indicating a reference to a footnote
>
> Under Annex A Footnote sections
> ADD
> 28) The expression that was is used as the argument to the $typeof
> system function shall contain no hierarchical references.
>
> Notes
> =====
> this proposal will also enable V2K style module declarations with type
> parameters such as
> module m1 #( /$typeof(A_bus) ) (input ....)/
>
> and the usage of the $typeof system function to declare type
> parameters in class, program and interface declarations as well.
>
>
>
> Thanks,
> Dan Jacobi, Intel Corporation
> 972-4-8655855
>

-- 
	_Matute
=====================================================
Guillermo Maturana, Ph.D.     Verification Technology
Synopsys Scientist            Voice: (650)584-5326
700 E. Middlefield Road       Fax:   (650)584-4115
matute@synopsys.com