[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnucap-devel] B element
[Gnucap-devel] B element
Thu, 31 Oct 2002 01:52:21 -0700
On Wednesday 30 October 2002 01:57 pm, Ko, Yao wrote:
> Would you happen to have some detailed architectural design
> documentation for Gnucap? I'm diving deeper into the source
> code to attempt to add the 'B' element. However, I couldn't
> find the explanation for all the classes and methods in the
> "Technical notes" of the manual, nor in the comments of the
> source code.
There is some info at ftp://progeny.isu.edu/pub/gnucap . I
don't have any more documentation of the architecture than what
The spice "B" device is a very difficult place for the first
attempt at working on the code. Gnucap is a mixed-mode
simulator, with much of the code in place to support
multi-rate, hierarchy, latency, and duplication. The
architecture is very much different from Spice. When you work
on primitive devices, you need to contend with all of this or
it will seriously degrade performance, if it works at all. I
am looking someone interested in doing Ph.D. study in this area.
I have already made a start on the B device. Some of the code
is there now. Some of it is in the IBIS package, which is also
The code there now is in the classes DEV_CPOLY_G and
DEV_FPOLY_G. These classes share the code to actually load the
matrix. They are already used in the BJT and MOSFET models.
There is also a DEV_FPOLY_CAP that can be used as a base for a
Q=expression form, with almost no additional effort. This too
is already in use in the BJT and MOSFET models.
What is needed to support the B device is the basic overhead
functions (parse, print, etc.), an expression evaluator, and
code to compute the derivatives.
There is an additional complexity with the B device due to the
syntax being different from other Spice devices. In all other
Spice devices, the connection list is explicit, mostly a node
list with an occasional branch name used as a current probe.
The B device has only the output nodes explicit. The other
connections must be extracted from the equation.
There is a subtle issue here in that the expression is in a
different scope than the connections. In Spice, the whole line
is a single scope. In Gnucap, the connections are a scope and
the expression has no knowledge of the connections. The
connections are parsed in a DEV_ class. The expressions are
parsed in a COMMON or EVAL class.
To manage this, it is necessary to make two passes over the
expression. The first pass, in the DEV_ class, needs to
extract the connections and map them to port 0, port 1, port 2,
etc. The second pass, in a COMMON class needs to build the
evaluation tree. The code I have in the unreleased IBIS
section builds it as a pair of stacks. It is then necessary to
generate the derivatives, with respect to each port.
In tr_eval, the function and derivatives need to be evaluated,
then passed in through the set_parameters function.
Supposedly, the rest of it, everything I didn't mention here,
If you do it this way, the AC and pole-zero code is automatic.
Also, convergence checking and queue management are also
If you make a DEV_DS, derived from ELEMENT, you need to do all
Actually, the best way to do it is to add the parse and print
functions to the DEV_FPOLY classes, and a COMMON to manage the
expression. They don't have parse functions now because they
are only used through the model compiler.
In another mail, you asked about using the model compiler to
generate the B device. You could generate the functionality
but not the syntax.
The model compiler could be modified to accept Verilog-A or AMS
as an input language. This is in the plans. There is a lot of
important information missing in Verilog-A. This would need to
be supplied. Since Gnucap is a mixed-mode simulator, there is
no reason for it not to fully support Verilog-AMS and VHDL-AMS
eventually, by automatically running the model compiler and