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

From: Karen Pieper <Karen.Pieper@synopsys.com>
Date: Mon Aug 23 2004 - 11:29:18 PDT

>Message that bounced:

>To: "Jacobi, Dan" <dan.jacobi@intel.com>
>Cc: sv-bc@server.eda.org
>Subject: Re: [sv-bc] Partial proposal for issue #091- take #2
>References: <92C157534C58E44C9A5D517F0F3D733E013FDF76@hasmsx404.ger.corp.intel.com>
>In-Reply-To: <92C157534C58E44C9A5D517F0F3D733E013FDF76@hasmsx404.ger.corp.intel.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Content-Transfer-Encoding: 7bit
>X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a
> on server
>X-Virus-Status: Clean
>
>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
>>
Received on Mon Aug 23 11:29:26 2004

This archive was generated by hypermail 2.1.8 : Mon Aug 23 2004 - 11:30:05 PDT