Merging Gnucap and Qucs -- The Why and How

From F-Si wiki
Revision as of 09:01, 6 July 2022 by Felix (talk | contribs) (add abstract)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
  • Speaker: Felix Salfelder
  • email: felix@salfelder.org
  • other information: n/a

Abstract

Gnucap and Qucs are two complementary projects both created and distributed in the hope that they will be useful. In a nutshell, Gnucap lacks a graphical user interface that Qucs has, and Qucs lacks a developer friendly implementation and extensibility. In this talk I will highlight the individual strengths of these projects, and explain how they relate to other projects such as Ngspice. I will outline how the two prototype implementations, "Gnucsator" and "modular Qucs", target the interoperability between Gnucap, Qucs and beyond.

Gnucsator provides a simulator emulating Qucsator, the simulator used from within Qucs. It consists of a collection of Gnucap plugins that have been either implemented from scratch or as a wrapper around (unmodified) Qucsator model code. With very little effort, Gnucsator plugins allow the translation of netlists between Qucs and, say, Verilog file formats. More interestingly, simulation of a circuit with models from Gnucap, Qucsator, Spice3f5, NGspice etc. is straightforward.

The modular Qucs code base has evolved during refactoring Qucs, porting to Qt5, and turning inessential parts into plugins. During this process, the way to replaceable, alternative symbols, component models, simulators and file formats including data file formats has been paved. Some of these have been implemented and are workable, others are easy to add. As of now, the modular Qucs GUI, mainly the schematic editor, has too many bugs. Fortunately, the GUI is not essential for all tasks...

Merging the Qucs and Gnucap projects is a promising step towards a feature-rich circuit design and simulation tool. This is not only because internally, Gnucap and modular Qucs are very similar, but also because a single project will be easier to maintain, and easier to identify for potential contributors. A project that interfaces with other tools on different levels, more than trying to catch up, will have the potential to bring people together, potentiating the efforts. Historically, contributions have fallen into the cracks between projects, e.g. when authors failed to maintain their version of a program. A modular architecture will allow even incomplete contributions to be interesting to others, without stalling the development.