Bug in parsing Verilog-A code

[dwarning]

In the process of symbol generation code lines in the .va model like

// Process related parameters parameter real dl = -0.01E-6; // P(info="Channel width correction" units="m");
parameter real dw = -0.01E-6; // P(info="Channel length correction" units="m");
or
/* vto, kp and gamma with variation for MC analysis if required. * The default value for model parameters avto, akp and agamma
follow in wrong parameters in the instance symbol like
process=related
default=value
or similar.
Correct behaviour would be to ignore any commented line.

TODO list

• Exclude commented lines from parser
• Use preprocessor for Verilog-A files

[ra3xdh]

I need the full *.va source file to debug this issue. It may be more complex than it seems.

[dwarning]

I attached the project in my #365 including the ekv26.va.

[ra3xdh]

Yes, I confirm this. Qucs-S cannot recognize parameters in this file.

[dwarning]

I looked into certain files and saw blocks for skipping comment blocks from va files, e.g. vafile.cpp. This seems not to work. Which file is used for reading the va file parameter names and values to include in the json files?
BTW - Because latest cmc models using macros for instance and model parameters I am looking for a general solution in transform these model through a preprocessor into an expanded format. Maybe openvaf --print-expansion would be a candidate, but there are missing LF in the output at the moment.
Your opinion?

[dwarning]

May be it helps:
With the beta version of VAMPyRE (rel. in December) by Geoffrey Coram from CMC is it possible to preprocess any Verilog-A file. As a result you have a file with pure va text belong the VA standard 2.4 and striped any comment lines.
The parameter section will then have entries like, here summarized as examples:
`
parameter vto = 0.5; <- parameter default real type

parameter real vto = 0.5;

parameter real vto = 0.5 from( -inf : inf );

(desc= "Vth") parameter real vto = 0.5 from( -inf : inf );

(units= "V" , desc= "Vth") parameter real vto = 0.5 from( -inf : inf );

(units= "C" , type="instance" desc= "device deviation temp") parameter real dtemp = 0.0 from( -inf : inf );
`

Then I used a slight modified function Schematic::savePropsJSON
` QString module;
QStringList prop_name;
QStringList prop_val;
// QStringList prop_desc;
QTextStream vastream (&vafile);
while(!vastream.atEnd()) {
QString line = vastream.readLine();
line = line.toLower();
if (line.contains("module")) {
auto tokens = line.split(QRegularExpression("[\s()]"));
if (tokens.count() > 1) module = tokens.at(1);
module = module.trimmed();
continue;
}
if (line.contains("parameter")) {
auto tokens = line.split(QRegularExpression("[\s=;]"),qucs::SkipEmptyParts);
if (tokens.count() >= 4) {
for(int ic = 0; ic <= tokens.count(); ic++) {
// if (tokens.at(ic) == "desc") { // ToDo: extra loop over desc tokens?
// prop_desc.append(tokens.at(ic));
// }
if (tokens.at(ic) == "parameter") {
prop_name.append(tokens.at(ic+2));
prop_val.append(tokens.at(ic+3));
break;
}
}
}
}
}
vafile.close();

`
Sorry my C++ programming skills are very limited. So if the token parameter comes e.g. in a $strobe or in a comment the function still fabricates nonsense for the symbol json files.
It is possible to work w/o the Python tool from Geoffrey but then the effort in parsing the va file is enormous.
I let in the commented prop_desc filling as a placeholder.

I hope the formatting for code will not disturb the text.

[tomhajjar]

I found two old Verilog files from Qucs that seem to work. bsim3v34nMOS.va and bsim3v34pMOS.va

It's not obvious why these two files work and ekv26.va doesn't. Maybe they will help figure out the issue.

See #384 for more info on these files.

Verilog files.zip

[ra3xdh]

I decided not to fix this, but use the workflow proposed in #411 instead. It is free of parsing issues and allows any Verilog-A syntax extensions that OpenVAF can accept. New RCLDQM devices also could be mapped to N letter representing Verilog-A device. See #349 and #431 Old workflow with JSON files and Verilog-A parser should be kept only for backward compatibility with Qucsator/ADMS and not recommended for new design. Closing this as won't fix.