[Gnucap-devel] Logic .. history and moving forward.

[al davis]

On Mon, 30 Jul 2018 13:04:56 +0200
Felix Salfelder <address@hidden> 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.