B element

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 
is there.

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 
incomplete.

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, 
is done.

If you do it this way, the AC and pole-zero code is automatic.  
Also, convergence checking and queue management are also 
automatic.

If you make a DEV_DS, derived from ELEMENT, you need to do all 
this yourself.

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 
dynamic linking.

al.