Hi David, My perception is that the paramset ft does not replace the module ft. Just as the parameters given to a paramset instance are translated before passing them on to a module, the output variables of the module get translated by the paramset before passing them on to the user. The output variable of the paramset would only be processed when the output variable of the associated module would be translated. The most obvious use would be the situation when there is no ft in the module and you want to make it available to the user by using the output variables that you do have available. module npn(...); (*desc="gm") real gm; (*desc="cpi") real cpi; (*desc="cmu") real cmu; analog begin ... gm = ddx(Ic, V(b,e)); cpi = ddx(...); cmu = ddx(...); end endmodule 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 I think paramset_constant_expression is not the right name. Where it currently says analog_function_statement in the 3rd BNF rule of A.9.1 I would expect a paramset_analog_statement. This would be the same as an analog_function statement except that the procedural assignment would have a left-hand expression that supports the ".module_output_variable_identifier" syntax. It does not have to be constant -- it only has to be without state, just like an analog function statement. Cheers, Marq -----Original Message----- From: owner-verilog-ams@server.eda.org [mailto:owner-verilog-ams@server.eda.org] On Behalf Of David Miller Sent: Wednesday 5 August 2009 17:13 To: verilog-ams@server.eda.org Subject: 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Aug 5 08:42:09 2009
This archive was generated by hypermail 2.1.8 : Wed Aug 05 2009 - 08:42:31 PDT