Differences

This shows you the differences between two versions of the page.

Link to this comparison view

gnucap:user:language_plugin_for_qucs [2018/07/07 17:36]
felixs some additions and rewording
gnucap:user:language_plugin_for_qucs [2018/09/10 05:44] (current)
felixs more on gucsator
Line 3: Line 3:
 The basic idea is to parse a qucs schematic or a qucsator netlist. The basic idea is to parse a qucs schematic or a qucsator netlist.
  
-== gnucsator ==+=== gnucsator ===
  
 qucsator is the default simulation engine behind the qucs user interface. it does dc/ac/tran and sparam analysis, and maybe a (simplified, linear?) kind of harmonic balance. qucsator is the default simulation engine behind the qucs user interface. it does dc/ac/tran and sparam analysis, and maybe a (simplified, linear?) kind of harmonic balance.
  
-The use is quite limited due to the interface between qucs and qucsator, but it defines sort of interface between the projects.+The interface between qucs and qucsator is limited, but it is the only half way stable interface to simulator.
  
-gnucsator aims to be a drop-in replacement for qucsator, that means it will +gnucsator is a drop-in replacement for qucsator, that means it 
-provide the components implemented in qucsator, +  provides some of the components implemented in qucsator, 
-have to read the netlist (unless/until somebody fixes this) +  parses the netlist.txt files meant for qucsator (until this is no longer necessary), 
-interpret simulation commands (embedded into the netlist) like qucsator. +  interprets and wraps simulation commands (embedded into the netlist) much like qucsator, then 
-produce output equivalent to qucsator output ("dat" file format).+  produces output equivalent to qucsator output ("dat" file format). partly implemented as shell script currently.
  
 == Example of a qucsator netlist file == == Example of a qucsator netlist file ==
Line 43: Line 43:
  
 TODO. tl;dr; some upside-down xml inspired layout without simulation labels. TODO. tl;dr; some upside-down xml inspired layout without simulation labels.
- 
  
 == description of the simulation commands == == description of the simulation commands ==
  
-TODO.+gnucsator currently wraps gnucap DC and TRANSIENT analysis, and also imitates qucsator SPARAM analysis. qucs does not define an execution order. there is more work in progress on the qucs side.
  
-== Description of a schematic file ==+=== Description of a schematic file ===
  
 The schematic format used in qucs is not currently used for simulation purposes. Qucs compiles an intermediate self-contained circuit representation ("netlist") including simulation commands before invoking qucsator. Hence the format used for the schematics (some XML-like format) is not relevant yet. It will be easy to represent the schematic as a standardized (e.g. verilog) netlist, once Qucs supports additional file formats. This will make the schematic files more useful and the intermediate netlists obsolete. The schematic format used in qucs is not currently used for simulation purposes. Qucs compiles an intermediate self-contained circuit representation ("netlist") including simulation commands before invoking qucsator. Hence the format used for the schematics (some XML-like format) is not relevant yet. It will be easy to represent the schematic as a standardized (e.g. verilog) netlist, once Qucs supports additional file formats. This will make the schematic files more useful and the intermediate netlists obsolete.
  
-== Implementing the Components ==+=== Implementing the Components ===
  
 Qucs essentially provides a hardcoded set of components plus variants (paramsets) through a "component library". We need to provide (most/all) of the components supported by qucsator. It would be possible to wrap them, on an implementation/binary level using a wrapper similar to spice_wrapper (e.g. http://git.savannah.gnu.org/cgit/gnucap/gnucap-plugins.git/tree/qucs_wrapper.cc?h=qucs). This involves some effort and workarounds with no clear benefit. In particular, there are only few components, this could be used for. Qucs essentially provides a hardcoded set of components plus variants (paramsets) through a "component library". We need to provide (most/all) of the components supported by qucsator. It would be possible to wrap them, on an implementation/binary level using a wrapper similar to spice_wrapper (e.g. http://git.savannah.gnu.org/cgit/gnucap/gnucap-plugins.git/tree/qucs_wrapper.cc?h=qucs). This involves some effort and workarounds with no clear benefit. In particular, there are only few components, this could be used for.
  
 The approach here The approach here
-https://git.savannah.gnu.org/cgit/gnucap/gnucap-plugins.git/tree/STATUS?h=qucs aims at implementing the components in terms of modules that (re-)use some functionality of existing gnucap components. Some components can be directly wrapped through a subcircuit declaration or paramset. Others can be easily represented by subcircuits containing few components (a.k.a. macros). Ideally all components would be implemented in verilog-A. At the current stage it would make more sense to support user provided Verilog-A models in qucs. Some work has been done in that direction, but qucsator will not support Verilog-A input in the foreseeable future.+https://git.savannah.gnu.org/cgit/gnucap/gnucap-plugins.git/tree/STATUS?h=qucs implements many of the components in terms of modules that (re-)use some functionality of existing gnucap components. Some components can be directly wrapped through a subcircuit declaration or paramset. Others can be easily represented by subcircuits containing few components (a.k.a. macros). Ideally all components would be implemented in verilog-A. At the current stage it would make more sense to support user provided Verilog-A models in qucs. Some work has been done in that direction, but qucsator will not support Verilog-A input in the foreseeable future
 + 
 +=== extras === 
 + 
 +gnucsator is based on gnucap with a view towards standard compliance. 
 + 
 +  * gnucap provides additional functionality, such as interactive analysis, measurements, scripting and data conversion, which is not covered here. e.g. a netlist.txt can be directly fed into an interactive session. 
 +  * the component library aims at implementing all qucs components in a standard language (verilog and variants). there will be no need to do it all over to support other (standard compliant) simulators.
gnucap/user/language_plugin_for_qucs.txt · Last modified: 2018/09/10 05:44 by felixs
 
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Run by Debian Driven by DokuWiki