Merging Gnucap and Qucs -- The Why and How

From F-Si wiki
Jump to navigation Jump to search
  • Speaker: Felix Salfelder
  • email: felix@salfelder.org

Downloads

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.

Software

General information

Roadmap

  • The software (Gnucap) wishes to interface with the following tools: gEDA, KiCAD, NGspice, Qucs (and forks), Xyce etc.
  • The project seeks help on: Finalising the merger. Building bridges to (and between) other projects. Establishing substantial funding for further development and VerilogAMS support.