Open felix-salfelder opened 2 weeks ago
ra3xdh
commented
2 weeks ago I have read you proposal about new unified schematic file format here: http://gnucap.org/dokuwiki/doku.php/gnucap:user:netlist_import_and_export I understood that you are intending to propose it as the unified interchange format for the FOSS EDA tools. Did you inform the developers of another tools? Otherwise you will only obtain "XKCD Standards".
felix-salfelder
commented
2 weeks ago On Sun, Nov 10, 2024 at 08:26:41AM -0800, Vadim Kuznetsov wrote:
I understood that you are intending to propose it as the unified interchange format for the FOSS EDA tools. Did you inform the developers of another tools?
Yes.
Otherwise you will only obtain "XKCD Standards".
Sorry Vadim, you are completely missing the point. IEEE 1364-2005 is an established standard already. There is no way around the sections we use when moving on towards SystemVerilog, Verilog-AMS, or just simply Verlog-A. It could even lead to Qucs-S done right, but that's your call.
ra3xdh
commented
2 weeks ago IEEE 1364-2005 is an established standard already.
Yes, this document defines the Verilog syntax. But could you provide a reference where the symbol drawing or the schematic title page representations are defined in this document? Do the C++ libraries implementing the Verilog parsers etc. exist? There is a lot of work ahead.
felix-salfelder
commented
2 weeks ago On Sun, Nov 10, 2024 at 09:00:41AM -0800, Vadim Kuznetsov wrote:
> IEEE 1364-2005 is an established standard already.
Yes, this document defines the Verilog syntax.
Syntax and semantics.
But could you provide a reference where the symbol drawing or the schematic title page representations are defined in this document?
Symbol drawing is implemented in many applications. Qucs is one of them, it does not need any changes, and nothing about it requires Verilog.
The schematic title page. I think I understand what you are getting at. In a Qucs schematic, there is stuff at the start of the file, that you wouldn't consider part of the circuit. There are ways to carry it along anyway without breaking compliance with Verilog grammar. The purpose is to ignore it, when it is not needed. The easiest approach is, verbatim, in an attribute.
"""
( S0_qucs_xml_header="
But nothing wrong with a more structured representation
""" ( S0_qucs_page_width="3" ) ( S0_qucs_page_height="7" ) ( S0_qucs_page_title="My New Circuit" ) [..] module some_circuit( .. ); // circuit goes here endmodule; """
Do the C++ libraries implementing the Verilog parsers etc. exist? There is a lot of work ahead.
There is a Verilog parser in every tool that processes Verilog files. Structural Verilog is particularly easy to parse and interpret, and that's all we need for starters.
The nontrivial bit that is still missing in Qucs is explicit connectivity and named parameters. This leads to the change we need for this. So instead of dumping
""" <Resistor R1 1 123 345 "1" "0" "3" "7"> """
some digging into the data is needed to figure out what it really means. Here it will look something like.
""" ( $xposition="123", $yposition="345", S0_qucs_symbol="Resistor.svg" ) Resistor #(.R(1), .tnom(0), .TC0(3), .TC1(7)) R1(.p(_net1), n(_net42)); """
We are not interested in Qucs specifics, only in the circuit. The internal representation in Qucs may stay whatever it used to be. Qucs has not yet arrived at svg, you get the idea: svg would also work outside Qucs. There is no need to display symbols when simulating.
When parsing the schematic, Qucs may check if nets connect as intended, and parameter names match. Missing the opportunity is not even a regression.
Hope this is getting clearer now.
tomhajjar
commented
2 weeks ago Lessons should be learned from how QucsStudio has "devolved". Old schematics are not supported and changes made to the file format under the guise of adding PCB capability has failed. One needs 3 versions of QucsStudio to use older projects. The so called PCB extensions are worthless. The "latest" version of QucsStudio is old and has bugs that may never be fixed.
KiCAD's added simulation capabilities are version specific. A project done under version 6 may not work under newer versions. One is forced to either have multiple versions of KiCAD or update every project like QucsStudio requires.
Also what is gained by changing file formats when ngspice won't be changing in concert?
felix-salfelder
commented
2 weeks ago On Sun, Nov 10, 2024 at 01:52:16PM -0800, tomhajjar wrote:
Lessons should be learned from how QucsStudio has "devolved". Old schematics are not supported and changes made to the file format under the guise of adding PCB capability has failed. One needs 3 versions of QucsStudio to use older projects. The so called PCB extensions are worthless. The "latest" version of QucsStudio is old and has bugs that may never be fixed.
Qucs schematics are fragile for the reasons explained earlier. Old schematics would not be worthless if they contained complete circuits rather than what could be characterised as incomplete drawings.
Here's a quiz, in an attempt to make it a little more clear.
Look at the Resistor instances current vs. proposed. Which one is easier to make sense of, regardless of the Qucs GUI version? Now imagine, far future. You find the Qucs version number at the top of the old schematic file, to five digits. (Assume Qucs is long dead and won't compile). Also, you have totally forgotten about Verilog syntax. Now which of the Resistors is easier to work with? Bonus points: Imagine two of them, with a connection in between.
KiCAD's added simulation capabilities are version specific. A project done under version 6 may not work under newer versions. One is forced to either have multiple versions of KiCAD or update every project like QucsStudio requires.
Interchange between Qucs and KiCAD should focus on standard representation of circuit models. These won't break across tool versions. At the very least, the rules won't change all the time, and the relevant data will be permanent in principle, easy to validate, easy to fix.
"QucsStudio". Not sure what they are trying to achieve. The combination "nonstandard" and "closed source" raises a red flag. Also known as lock-in. Perhaps standardisation may strenghten the bridges to non-free tools. I do not personally believe that these tools will benefit much from it, as standardisation is the seed for competitive high quality free implementations.
Also what is gained by changing file formats when ngspice won't be changing in concert?
Ngspice does not understand schematics, and offers no uniform syntax for device instanciation. Ngspice requires schematics to be "netlisted", known issue from Qucsator. Moving to a self contained standard schematic format will not change anything about the internal representation within Qucs, nor the way netlists for ngspice are created. After all, the goal here is not to fix the problems with ngspice, but to standardise circuit representation and schematic interchange. Improvements like decoupling could be implemented by the interested parties.
The file format used for schematics not suited well and needs a replacement.
Connectivity is implicit. The parser, netlister and everything in between relies on guesswork to make connections between devices. This guesswork depends on a device library, an unnecessarily and tricky to manage moving target. We need named signals/wires/nodes and named ports, as well as explicit connectivity.
Parameters are by position. Parameter names are implicit, but required by the netlister, and simulators. This requires a fragile mapping that unnecessarily relies on a symbol library. Currently, it is hard to validate that a device in a library satisfies symbol used in a schematic.
The simulator lock-in is mainly a consequence of the above. The idea here is to make simple things simple, and harder things possible. One option is to use the IEEE 1364-2005 inspired format (see ROADMAP), but any other that fixes the above points will be fine for now.
There is funding available for this work.