Re: No BNF support for .module_output_variable_identifier

The module doesn't get ft, but an instance of smnpn will.

In your example, the value assigned in the module is irrelevant;
the paramset overrides the computation so you get 1/(2*`M_TWO_PI)
for all time.

It's a little asymmetric that the output variables of the module
are automatically promoted (if not overridden), whereas the
parameters of the module are *not* parameters of the paramset.
However, this is thought to be the way most people would want
it to work (and we don't want to force them to declare a
bunch of pass-through variables to promote them -- ft = .ft;
gm = .gm; etc.).

-Geoffrey


David Miller wrote:
> 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?
>>>>
>>>
>>
>>
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.