Re: No BNF support for .module_output_variable_identifier

Ok, I am a little confused here.

paramset smnpn npn; // small npn paramset
   (*desc="cut-off frequency"*) real ft;
   .is=2.0e-17; .bf=120.0; .br=10; rb=145; .rc=75; .re=12;
   .cje=2.0e-14; .vje=0.9; .mje=0.4;
   .cjc=3.0e-14; .vjc=0.6; .mjc=0.3; .xcjc=0.2;
   ft = .gm/(‘M_TWO_PI*(.cpi + .cmu));
endparamset

so does this mean that the module npn will automatically get a real variable ft 
when instantiated via this paramset smnpn?

If the variable ft exists in the moduel npn already, it says we replace it. 
Consider this silly example:

module npn(...);
   (*desc="cut-off frequency"*) real ft;
   (*desc="gm") real gm;
   (*desc="cpi") real cpi;
   (*desc="cmu") real cmu;

   analog begin
     @(initial_step) begin
       gm = 1.0;
       cpi = 1.0;
       cmu = 1.0;
       ft = 2;
     end
     @(timer(5n))
       ft = 0;
   end
endmodule

At the end of the initial step is the value for ft 2 or 1/(2*`M_TWO_PI).

At time 5ns, is its value now 0?

I am just unsure how this "replacing" actually works.
I was misunderstanding how this paramset output variable is being used. I don't 
think it should be part of the paramset_constant_expression, as it is certainly 
not constant in any sense.

Cheers...
Dave



Geoffrey.Coram wrote:
> David -
> In the expression for "ft" that you cite, gm, cpi, and cmu are all
> output variables -- that is, they depend on the operating point
> and are dynamic quantities.
> 
> We do need a definition for paramset_constant_expression (it's used,
> but I don't see a definition in 2.3.1).  I think I'm agreeing with
> Marq, though, that module_output_parameter_identifier need not go
> in this list; I think it could be circular to allow this, since
> the paramset_constant_expression could be used in assigning module
> (input) parameters, which are then used to compute the "output
> parameters."
> 
> But also in paramset_statement, where we have analog_function_statement,
> we need some BNF to allow the ft statement.  Analog functions,
> as I recall, aren't allowed to access module parameters.
> 
> -Geoffrey
> 
> 
> David Miller wrote:
>> 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.