On Mon, 30 Jul 2018 13:04:56 +0200 Felix Salfelder <[email protected]> wrote: > i am trying to make the logic more verilog friendly (accessible, to > begin with). This is required for gnucsator, because a global logic > modelcard does not play with gate parameters, and local modelcards do > not connect properly ("different logic models used..."). the "logic" > branch fixes this.
Moving forward .. The logic devices and "connectmodule" code should become plugins, and be made compliant with verilog-AMS and VHDL-AMS. History .. The existing design is about 30 years old. The code is about 25-30 years old. It predates even chat about what is now the *AMS languages. It predates XSpice. The only changes since then have been to fit other changes, most significantly the move from C to C++, and that was never really completed. Using Verilog terminology .... There are different kinds of signals .. "disciplines", which in verilog are user defined to some extent. There are two basic kinds of signals, "domains". The "domain" can be either "continuous" or "discrete", which is explicitly stated. The "continuous" domain has two variants "conservative" or "signal-flow", which is implied. "Conservative" disciplines have two "natures", a "potential" and a "flow". "Signal-flow" disciplines have one "nature", just a "potential". A "connectmodule" defines how to convert between "disciplines". In gnucap, the "continuous" domain is the analog side. We think of it as voltage and current. Gnucap does not distinguish between "conservative" and "signal-flow" disciplines. The "logic" domain is represented in the "LOGIC_NODE" class. Actually, gnucap does more there. The LOGIC_NODE also represents the "connectmodule". A "NODE" really contains just an index, that is used to find the real storage. For "continuous" that would be in the matrix, right-side, and solution vectors. For "discrete" it would be an array containing the logic state. Gnucap reserves a space for both continuous and discrete at every node. You might think that is wasteful because most of the time only one or the other is actually used at a particular node. It's a small waste compared to other overhead, two doubles per node for continuous, one enum (int) per node for discrete. So I didn't do anything about it. Doing something about it is likely to cost more than it saves. Moving forward .. The devices need to become plugins. The different kind of gates should be different devices, not variants of a device, so new ones can be added. The "connectmodule" also needs to become a plugin, so new ones can be added. A LOGIC base class that inherits from COMPONENT needs to be created. A CONNECTMODULE base class that inherits from both ELEMENT and LOGIC needs to be created. Is the separate LOGIC class really necessary? It can wait. I think the "logic-1" branch is moving in the right direction. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
