verilog language plugin

[felix-salfelder]

this is based on the other PR, actually just one commit.

the verilog specific code does not touch the schematic code.

[felix-salfelder]

this is now functional and ready for merge. the travis thing has again stalled, so could someone retrigger the check please?

[ra3xdh]

At first, CMake build is broken. Qucs could be built but then crashes if it is executed. Autotools build has no visible problems.

At second this PR is becoming a real "patchbomb". This solution is raw, and it' not time to merge it before release. Also see my arguments at #275 discussion thread. I strongly don't recommend to merge this PR.

[felix-salfelder]

can you suggest what to do differently or better, i'd be happy to change it.
you are right about not merging before the 19 release. in #275, i suggested to open an integration branch for a future release, it would bother me a lot to just sit there and wait.

let me see what i can do about the cmake crash... can you provide some details on your platform or a logfile? EDIT: rebuilt using cmake both with gcc and clang, could not reproduce the crash.

thanks

[nvdl]

Possibly, it is better to put "netlang" as the property of the "Schematic" class object.
Schematic::getNetlist can return the netlist then.
You can get rid of "NetLang const*" in many functions. I am opting for keeping the function call changes minimal.
If there is something else in the future that may also affect the netlisting, we should not be passing that through functions.

[felix-salfelder]

"netlang" as the property of the "Schematic" class object.

no, a schematic is not of any language. just a schematic.

simllarly, when dumping a schematic into pdf, there's no point in telling the schematic beforehand. but that brings me to the idea that the pdfWriter is actually a netlist plugin. similarly, the .sch-writer must also be a "netlister".... these are indentically structured as it seems.

sure, "NetLang" is not general enough a name for this thing. can you think of a better name?

[nvdl]

Did not dig more but is there a "Netlister" class that takes in the schematic and generates the netlist based on its current language?

As I see it, there should be 4 steps to implement a new simulator.
1: Teach "Netlister" about the new netlist for sim-x
2: Teach the "ProgressMonitor" to interact with sim-x while simulation is in progress
3: Teach the "DataParser" to load the data
4: Add the new sim-x name to global enum "simulator"

The user changes the simulator that updates a global enum "simulator"; most possibly in "QucsSettings". The "Netlister" knows which "language" to use and which simulator to invoke, the "DataParser" knows which method to use to parse.

sure, "NetLang" is not general enough a name for this thing. can you think of a better name?

The enum can handle that.

Modifying each function with bools or other parameters is not an optimal approach.
Moreover, many of the functions that are lying around should be claimed by classes.
That is the first step to organize the codebase of qucs.

There is an assumption here; one type of netlist and one type of data file per simulator dictated by a single enum value.
I do not see if there many ways for netlisting for a single simulator.
For data file, we can go with the most efficient one (in terms of lookup and storage).
For example LTSpice supports both text and binary data outputs and they do not recommend text output.

[felix-salfelder]

Did not dig more but is there a "Netlister" class that takes in the schematic and generates the netlist based on its current language?

probably there should be one, so it remains possible to exchange it. i can only recommend to take a look at the list command implementation in gnucap. in gnucap, we have commands, we don't need that here, but the algorithm we want is close to list.

As I see it, there should be 4 steps to implement a new simulator.

dont confuse the netlister with what i called NetLang. NetLang only defines the language. the netlister merely visits the schematic elements. we should really try to work towards a singe netlister.

2: Teach the "ProgressMonitor" to interact with sim-x while simulation is in progress

no. the progress monitor should not change. why would we need different progess minotors for different simulators? we should start with the simulator-options dialog, this is more obviously simulator independent.

The enum can handle that.

huh, how would an enum propose a name for the netlister?

let me propose one: how about SchematicSerializer (sounds awful), or how about SchematicStreamer (sounds pretty technical).

Modifying each function with bools or other parameters is not an optimal approach.

the functions that are language specific should not even be implemented as part of the language class. it would be okay to modify the netlister with bools or enums, but only in a sensible way (such as: "order alphabetically or by position" and "collapse wires" and "dive into prototypes"). this could be done more elegant simply by inheritance. (which ones do we actually need?)

for example, collapsing the wires to nets is used for all spice simulators, it should obviously be implemented only once.

There is an assumption here; one type of netlist and one type of data file per simulator dictated by a single enum value.

no such assumption applies. but i dont really know what you do here.

For example LTSpice supports both text and binary data outputs and they do not recommend text output.

this is part of class LTspice : public Simulator, so it does not matter here. a simulator has a list of options ("properties"). add an option "usebinarystuff" to LTspice, let the user set it or not. the rest of qucs does not need to know about it, except the options dialog. but the options dialog should only see a boolen property and display a checkbox.

as a next step (after the merge debacle has settled...), we should finish the other NetLang (SchematicStreamLang?) classes and streamline the netlister/SchematicStreamer.

[nvdl]

we should really try to work towards a singe netlister.

Same here.

why would we need different progess minotors for different simulators?

Because every simulator spits out the progress status in a different manner.
Is there a universal progress format for the simulators?

huh, how would an enum propose a name for the netlister?

Each enum value will be tied to a specific netlisting language. Since, there is going to be a single netlisting class, the class will know about the language through this global value. This will help avoid modifying the functions and passing the net language as a parameter.
How are you looking at net language name? Why can't an enum represent it?
I am leaning towards usings enums rather than #define or string for the name.

the functions that are language specific should not even be implemented as part of the language class

Have you added the description of language class and what it does? I assumed that netlister accepts net language as a parameter and does the whole job.

no such assumption applies. but i dont really know what you do here.

Well, let's skip it for a while or drink more coffee and read it again. 😉

SchematicStreamer

What does it do and how does it connect to the other classes?

In QEP:

Schematic->netlist(s->NetLang(), TextFile(path));

Should be Netlister(Schematic *s, Simulator *sim, string TextFile);
The Netlister then uses sim->netlistingLanguage to do the work.
If Simulator *sim is used as above, forget about the enum discussion.

so it does not matter here. a simulator has a list of options ("properties"). add an option "usebinarystuff" to LTspice

I agree, but you missed the point; text output is slow and inefficient.

Moreover:
It will be nice that you keep on updating the QEP to get a better picture.
I do not want to mess with that in the beginning.

[felix-salfelder]

Because every simulator spits out the progress status in a different manner.
Is there a universal progress format for the simulators?

the progress bar only needs to know the current progress. the Simulator class runs the simulator (whichever way) and only needs to pass numbers to the progress bar. choosing a progress format shouldn't be rocket science, how about a short unsigned? (and more elaborate things if you intend to have more elaborate progress bars).

Should be Netlister(Schematic *s, Simulator *sim, string TextFile);

no. the netlister does not even need to know that we have a simulator at hand. we only need to specify the language. and no again, we need to pass a reference to a stream, not a string.

so we actually have virtual void NetLister::do_it(Schematic const*, NetLang const*, someStreamType&), except that i still don't like the names "NetLister" and "NetLang".

I agree, but you missed the point; text output is slow and inefficient.

no. i want to deliberately make it an implementation detail of the simulator class whether or not text files are used at all, this way you can start with the current approach (and just move code around) and then implement another simulator plugin that does the same, but efficient.

Moreover:
It will be nice that you keep on updating the QEP to get a better picture.

i will give it a try later this evening. i should also add an independent QEP (how about a PR?!) on the netlister base class.

[in3otd]

I agree, but you missed the point; text output is slow and inefficient.

no. i want to deliberately make it an implementation detail of the simulator class whether or not text files are used at all,

agree. For my typical simulations the fact that text output might be slower and take up more space than a binary format is inconsequential. Leave the choice of the simulator output format to the user. Text is nicer for post processing, usually.

[nvdl]

no. the netlister does not even need to know that we have a simulator at hand. we only need to specify the language. and no again, we need to pass a reference to a stream, not a string.

I generally use QEP in context.

Simulator const* s = getMySimulator(); // or maybe Document->getCurrentSimulator()?
Schematic->netlist(s->NetLang(), TextFile(path));

So, if you are not consistent with the QEP, I have no way to read your mind.

Because every simulator spits out the progress status in a different manner.
Is there a universal progress format for the simulators?

By, that I meant the processor of the output from the simulator (during simulation); warnings, etc.
That should be part of the Simulator class; my bad. No need to introduce more stuff.

choosing a progress format shouldn't be rocket science

As above. Of course, as a start, we dump everything to a text box.

Once again:

SchematicStreamer

What does it do and how does it connect to the other classes?

except that i still don't like the names "NetLister" and "NetLang"

"Netlister": "SchematicTranslator"
"NetLang": "TranslationLanguage"; "TranslationMethod"

I personally do not like the "language" thing at all.

how about a short unsigned?

Well, if you do not like to discuss the details; fine but I have never encountered this data type!

i will give it a try later this evening. i should also add an independent QEP (how about a PR?!) on the netlister base class.

Go for a PR or these stories will never end.

[felix-salfelder]

So, if you are not consistent with the QEP, I have no way to read your mind.

lucky you! :D. anyway

schematic->netlist(s->NetLang(), TextFile(path));

and

 Netlister::do_it(schematic, s->NetLang(), TextFile(path));

are essentially the same. except the second would permit multiple netlisters. i am still unsure if we really need/want multiples.

"Netlister": "SchematicTranslator"

to me, "translator" feels misleading. a translation sounds like something lossless. netlisting looses information. so does printing into png/ps/png. if you "translate" a book, then what you get will also be a book. this does not hold for the netlister. hence, i prefer "serializer", which is more correct...

I personally do not like the "language" thing at all.

this is debatable. which class should in your opinion implement how an item is represented in the output stream?

Go for a PR or these stories will never end.

ok. there's one PR. this. do you suggest any changes?

[felix-salfelder]

does not work on appveyor. i think i need the platform dependent interface stuff prepared in #458...

[ra3xdh]

Here is a set of test schematic and commented netlist that should be processed by future SPICE netlister:

• Sample RC schematic. Could be opened with both Qucs and Qucs-S. https://gist.github.com/ra3xdh/ebf8460d6dba0cdb8ccc4456e734bf14
• Commented netlist obtained from this sample schematic. This netlist is generated automatically by Qucs-S. Only comments added manually. https://gist.github.com/ra3xdh/e0aa16146f1e03b17d9b5f5de9c75d83

This schematic uses parametric equations, two simulations, and postprocessor equation (Eqn1). I see the following problem that makes automatic generation of such SPICE netlist difficult with you netlister:

• printItem() is called only once at Schematic::createNetlist . It's need to process every component more than once. Look at the equation component. Some equations go to .PARAM section, but other to Nutmeg section.
• It's need to scan schematic recursively to form the list of variables in write operator. Not only components are scanned by netlister, but also wires.

Generic netlist may have at least four sections:

1. Preamble. Some common directives for all circuits. Such as mathematical functions definition.
2. Directives before siulation
3. Devices and models
4. Simulations execution and postprocessor directives.

Qucsator has only third section. Other are empty. But SPICE has all four. Verilog-A has only 1 to 3.

Currentlys we have the following scturcture of netlister algorithm:

foreach (Component is Schematic) {
   printItem()
}

But probably the following algorithm will be needed:

foreach (Component is Schematic) { // Directives before simulation
   printDirective()
}
foreach (Component is Schematic) { // Devices
   printItem()
}
foreach (Component is Schematic) { // Simulations and postprocessor
   printItem()
}

How do you suggest to solve these problems with netlist generation?

[ra3xdh]

Also here I post the list of unified devices supported by all simulators. They are:

• RCL passive devices
• Sources: Idc, Vdc, Iac, Vac, CCVS, VCVS, CCCS, VCCS.
• Semiconductors: Diode, BJT, MOSFET, JFET.
• EDD

These devices should be processed by every simulator.

[felix-salfelder]

set of test schematic

thanks

could you please open a pr with those, together with a command and the expected reference output? i will help turning them into unit tests.

will rebase this later (as soon as the other depencencies are merged). then we will see what it breaks.

there will be no spice netlister in this PR, please open a new one. lets do things systematically, one at a time.

[felix-salfelder]

How do you suggest to solve these problems with netlist generation?

i don't quite like the way directives and components are mixed up in the schematic container. i don't know what the best solution is.

perhaps we should either allow plugins for netlisting, that will give us anything we need. alternatives are flags for filtering out stuff, or even store the schematic data in a more useful way (i.e. grouped). maybe we should open an issue... need to think about it

see #689

[felix-salfelder]

now part of refactor branch. turned into (optional) demo/test.