non-free verilog devices

[felix-salfelder]

we should put them into a (non-free) extension package.

we need to implement a way to make use of such an extension.

[ra3xdh]

Yes, we should give user an opportunity to switch on and use non-free models. It is very important for production usage. For example, I was asked about BSIM support in Qucs.

But let's prepare new release first, and then begin development of this extension (dynamic models loader). This new extension will be unstable first time as every new software, because it will be developed from the scratch. And it should not be in new release. Otherwise we will get a lot of bugreports.

Also, removing of non-free models without existing alternative was too fast. It was need to develop an alternative solution first.

[felix-salfelder]

For example, I was asked about BSIM support in Qucs.

to be clear: we should support verilog-a, not one particular device model that you have been asked about.

Also, removing of non-free models without existing alternative was too fast. It was need to develop an alternative solution first.

no. it was wrong (illegal) to add them in the first place. if you wish to delay .19 even further, count me in. but you will have to convince the others.

[in3otd]

regarding when to release 0.0.19, I was somewhat "pushing" for a release, since last official one was 1 and a half years ago and in the meantime there were some important bug fixes and improvements. It's true that it was not clearly defined what needs to be in the release. I have to agree with felix that non-free models need to be out, even if, of course, I too am not happy to have less models available. So any volunteer to prepare a non-free models package for 0.0.19 ? :grin:

[felix-salfelder]

So any volunteer to prepare a non-free models package for 0.0.19 ?

the package alone will not cut it. we must modularize symbols and implement a sane way to add more of them through extension packages. this is also required before we can add Vadims spice component symbols (which should also be made available by then).

it's all dead simple. to be realistic, we will have to do some cleanup. lets put it (yes, only this) into 0.0.20.

if there are volunteers: start with creating repositories and put the models/symbols there. no need to touch the master branch.

[ra3xdh]

@felix-salfelder , I will comment some of your points below.

we must modularize symbols and implement a sane way to add more of them through extension packages

Putting hardcoded C++ components symbols into loadable plugins also is not a good approach. We should use libraries for this purpose. We can put in libraries all symbols except ones that require dynamic parameters recalculation/transformation (for example simulations and file components). Using XML libraries will allow user to construct new devices without C++ programming. You can see an example of such implementation in Caneda project. It is fork of Qucs using Qt5. We need to extent our existing library format to enable such symbols. But don't develop library file format from the scratch!

User-defined dynamic components and other dynamic stuff may be placed into loadable plugins (*.so libraries).

this is also required before we can add Vadims spice component symbols

My SPICE components are also depending on my implementation of SPICE netlister. How to add them into new plugins system will depend also on what netlister will be accepted: my or your. These implementations are incompatible. I will try to wrap my SPICE devices into plugins when your plugins system will be ready for operation and sufficient stable. Let's discuss it after release and concentrate on release preparation now.

[guitorri]

+1 for moving away from qucs/components/*.{h,cpp} to text based symbols and libraries. I don't see the point in having to compile a component to have it rendered in the screen.

The current qucs -doc already dumps pretty much all the static info we need, see createDocData. It is matter of writing that data into a valid schematic (or library) file format (note that our current format is not valid XML).

We could already adopt a QDomDocument to represent the internal data structure. Tie that to a QGraphicsScene and we are more than half way of removing the Qt3Support graphics. Later it would be interesting to port the current schematic a valid XML format. Any read[Format] and write[Format] method will have to process information contained in the "model". Readers and writers will do the job for different file formats (these could be plugins). This way we can support the existing Qucs file formats, add new and migrate things forward. On top of that, we will have a clear model-view-(controller) approach to things which is very natural for UI.

All is left to do is create one component/symbol that renders from the text file (or library). My crappy vacomponent does just that. In this case, adms is used to dump the Verilog-A properties as a json file (because I was lazy to parse it), the symbol drawn in the symbol edit mode is converted to json on save (because I was lazy to write a converter). The vacomponent loads the json containing needed information for a symbol (lines, arcs, ..., ports, properties) and hand it over to the painter. The diagrams are ported as QGraphicsItem elements and we are good to go.

Any netlister will have to work based on the information contained in the model (be it QDomDocument or QGraphicsScene internal "model"). We will need a few netlisters: qucsator, spice, verilog, VHDL...

Loadable plugins are not necessarily for the component symbols (should not IMHO). With exception of qucsator where (at least non-free) verilog-a models will have to be loaded dynamically as plugins. This is available now in qucsator (in a very rough and brittle way).

For release, if someone have an idea for #335... I think that fixing that we are pretty much done with 0.0.19. People downloaded much more often the portable (zip) instead of the installer (exe). We should have that fixed.

[felix-salfelder]

+1 for moving away from qucs/components/*.{h,cpp} to text based symbols and libraries. I don't see the point in having to compile a component to have it rendered in the screen.

the only way to do that is to move the current components into plugins and then add one plugin for the others. one plugin per format (.sym, svg, kicadsym). and anybody is free to load symbols of any kind, even those written in c++ (such as vadims symbols).

Putting hardcoded C++ components symbols into loadable plugins also is not a good approach

@ra3xdh: right. but we must continue to support those symbols. at least for a transition period. the good news is: we will get this (almost) for free.

let's discuss a symbol base class in another thread/PR. i have got something in the pipeline...

[ra3xdh]

the only way to do that is to move the current components into plugins and then add one plugin for the others

Modularity may help with these components, but it's not necessary. All could be done a much simpler. VA-modules could be compiled on-the-fly during the circuit simulation. It's able to use the following algorithm:

1. Introduce <VA-code>...</VA-code> section in libraries. Modify LibComp class to allow to extract this section and save it into a file.
2. Put non-free verilog devices into the special library. Put Verilog-A sources into the <VA-code>...</VA-code> section.
3. Scan all components in Schematic class for library components (LibComp) before simulation.
4. If LibComp contains VA-model source, then extract it into temporary file, process it with ADMS build it and tell qucsator kernel to load it with -m option.
5. Simulate circuit and obtain outputs.

[felix-salfelder]

simpler [..]

actually, what you propose is quite a lot harder, when it comes to dealing with future plans. let me explain.

VA-modules could be compiled on-the-fly during the circuit simulation.

this is exactly what I want to do. but it will be different, depending on which simulator is in use. (surprise: gnucsator can do this already).

Put non-free verilog devices into the special library. does not make sense at all. there's nothing special about verilog devices. it must be possible to attach one to any symbol. we should not aim for workarounds, they will just fall on your feet later.

<VA-code> is overcomplicating issues. all we need is a reference to a .va file name, so the simulator (or simulator driver) can handle it. LibComp is a hack, we should prepare to replace by symbol_svg. the sooner the better.

can you implement verilog compilation on the qucsator end? i mean somehing like qucsator -a somefile.va -i netlist.txt should really be working by 0.0.20.

[felix-salfelder]

@ra3xdh and another remark: with modular symbols, you will be able to use your modified version of LibComp. if you insist, put it to qucs/contrib/libcompVA (or something like that), and you will not have to touch stable code.

(no it still does not make sense, think about it. please.)

[felix-salfelder]

see QUCS/qucs-nonfree