Re: No BNF support for .module_output_variable_identifier

From: David Miller <David.L.Miller_at_.....>
Date: Mon Aug 03 2009 - 08:03:47 PDT
Hello Surya,
it appears to be an oversight. We don't have a rule to match the 
module_output_variable reference in:

ft = .gm/(‘M_TWO_PI*(.cpi + .cmu));

So .gm, .cpi, .cmu are module output variables. We don't seem to have any 
concept in the language of output parameters, only variables according to 3.2.1 
(I guess it may just have been implicitly implied).

So it looks like we should also extend 3.2.1 to allow output parameters as well 
as output variables.

And the paramset should only be referring to module output parameters, i.e. 
constants. The shouldn't be referring to variables (dynamic).

I believe this is what we would need in the grammar:

paramset_constant_expression ::=
    constant_primary
  | hierarchical_parameter_identifier
  | module_output_parameter_identifier
  | unary_operator { attribute_instance } constant_primary
  | paramset_constant_expression binary_operator { attribute_instance }
       paramset_constant_expression
  | paramset_constant_expression ? { attribute_instance }
       paramset_constant_expression : paramset_constant_expression

module_output_parameter_identifier ::=
    '.'module_parameter_identifier

Does this make sense?

If anyone sees something I am missing here, please speak up.

Thank you for raising this, I will add it to the Mantis database as something 
to address.

Regards
Dave


Surya Pratik Saha wrote:
> Hi,
> In Verilog AMS 2.3.1, section 6.4.3 Paramset output variables, there is
> an example of ".module_output_variable_identifier". But I could not see
> this in the BNF of paramset. Is it intentional or a oversight of LRM?
> 

-- 
==============================================
-- It's a beautiful day
-- Don't let it get away
--
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
==============================================

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Aug 3 17:38:59 2009

This archive was generated by hypermail 2.1.8 : Mon Aug 03 2009 - 17:39:23 PDT