Convert Qucs-s *.sch files into some readable format for EESchema.

[0range0range]

Hi all,

Is there a possibility to open Qucs-s schematic in EEschema? Are there working converters?

I only saw this one, but it was not updated for ages: https://github.com/Valber/qucs2kicad

The goal is to do a layout after simulation without redrawing schematics in EEschema again.

Additional possibilities with indirect conversions or some other ways are also appreciated.

At the moment import dialog in EESchema includes the following:

• Altium (*.SchDOC)
• CADSTAR (*.csa)
• Eagle XML (*.sch)
• EasyEDA std files (*.json)
• EasyEDA pro files (*.epro, *.zip)
• LTSPICE schematic files (*.asc)

What would creating such a converter take if one starts from scratch?

[ra3xdh]

I didn't see any converters from Qucs SCH to KiCAD. The project from @Valber seems to be abandoned and not operational anymore. The conversion is technically possible, but there is no developers to implement this. Remember that Qucs-S is not supported by any organization (like KiCAD) and there is no full time developers in the project. You have to ways to implement this option: add converter yourself or find a developer to implement it. The starting point may be implement something like Component::dumpKiCAD() method.

[ra3xdh]

On the other hand remember that the 99% of the PCB designs from KiCAD cannot be directly simulated. It is often required to split schematic into smaller parts and add supplementary devices to have success with analog simulation. The Qucs<-->KiCAD converted will have a very limited application only for some restricted class of electronic devices.

[ra3xdh]

The more actual task is to add link to microelectronics CAD software like KLayout. Unlike the system level PCBs, the most of IC designs could be seamless transferred from layout to simulator and back.

[ra3xdh]

LTSPICE schematic files (*.asc)

The adding of LTSpice support was explained here #113 The main concern is that the most of LTspice models contain LTspice extensions of SPICE-3f5. And these extensions still be not supported by Ngspice.

[ra3xdh]

Summarizing all above I am transferring this issue to Discussion/Ideas. May be reopened if one will find a developer for this task.

[leviathanch]

Just use KiCAD for quick solution. It already supports SPICE simulations out of the box.
For chip designs, I suggest to use OpenROAD, because there's already tools which automatically do netlist extractions.
A solution for the meanwhile, until @felix-salfelder and I finally got Verilog-AMS simulation working reliably, which will make the characterization of VLSI design SOOOOO much easier

[tomhajjar]

"It already supports SPICE simulations out of the box."

Yes with a large Caveat. Simulations done in the past or today have no guarantee of working for newer KiCAD releases. I tested a number of examples for Holger. Pretty much guaranteed you will have to edit your simulations at some point in time.

The revision of ngspice used for KiCAD is always many revisions older so some capabilities won't be available.

[ra3xdh]

Just use KiCAD for quick solution.

The SPICE simulation in KiCAD has several limitation. The KiCAD is a PCB design program, but not a simulation tool. RF and some advanced features are not supported. The simulation kernel switch is not supported.

A solution for the meanwhile, until @felix-salfelder and I finally got Verilog-AMS simulation working reliably

This exists only as a specification draft for several years.

[felix-salfelder]

Vadim wrote

This exists only as a specification draft for several years.

Please take the time to actually read it. It's not a draft, it is a reference to the relevant subset of a standard document, with an explanation how to use it (and partly, why). @leviathanch is implementing it now in Qucs. Qucs-S is your call. Import to EESchema is theirs.

Anyway, the dated first partial traces of our implementation of the spec solve todays Qucs-S issues (reportedly) of unknown origin. ra3xdh/qucsator_rf#32

OrangeOrange asked

What would creating such a converter take if one starts from scratch?

The hard bit is to sanitise the representation of the circuit, making it explicit. The conversion itself is relatively straightforward.

Vadim writes

LTspice models contain LTspice extension

Nonstandard extensions and/or naked Spice instances are a pain wherever they show up. This problem should be tackled separately. It just needs some degree of collaboration and coordination. There are too many of them.

[ra3xdh]

It's not a draft,

It will be a draft until it will be implemented in C++ and supported by existing EDA software (not only Qucs and Qucs-S). The implementation for old Qucs is in very early development stage. Standards definition is much more easier than its implementation, so the development may take a while. Now your proposal remembers the XKCD Standards.

[felix-salfelder]

Vadim. Please don't pick on "old Qucs". It is not productive. We decided to use Qucs without "-S" for technical reasons only. Clearly, some degree of collaboration may eventually help, and we missed the opportunity once already (Remember the distant past, when funding was still a dream). Now consider what we are up against: It is mainly the proprietary stuff.

Those sections you'd use in Qucs-S are implemented in both Icarus Verilog and in Gnucap. Both are written in C++ under a GPL license. David is working on Qucs as I write this. Foundational issue there is making connections explicit, required to support any useful standard. Completely orthogonal to syntax or markup or what-else-you-might-think-it-is.

I do not follow your remark on difficulty. And I probably disagree: A standard identifies semantics, conventions and data structures. Finding data structures is orders of magnitude harder than implementing them. Do not just believe it, consult someone you trust and who has experience with the subject.

Now your proposal remembers the XKCD Standards.

You are referring to 927 again. I recommend looking at [1]. You will find that the cartoon is about proposing new standards. Where is the explicit connection (pun intended)? Here are a few hard numbers.

IEEE1364: 590 pages, 40 contributors from 12 EDA companies
Verilog-AMS: 442 pages, 74 names from 16 companies

Do you have any trouble accepting that these exist? Do you hate them (why)? Do you have better plans? Are you simply waiting to use Davids code? Are you working on number 15? Please enlighten us.

Some of it should be covered in a roadmap for Qucs-S. I could not find it. Sure I am a bit nosy here, but a sensible roadmap can help with securing funding, too.

[1] https://www.explainxkcd.com/wiki/index.php/927