---
# System prepended metadata

title: Untitled

---

Hello Dietmar and Holger,

we have completed a first prototype of integrating OpenVAF with ngspice.
We would like to detail the current state of the project and ask you for checking our approach.

There are two steps:
               (1)                           (2)
Compiler OpenVaf  ---->    Shared object File  ------> Ngspice

We have completed most of (1), e.g. the compiler perfectly understands all models we could find, and 
can also generate corresponding machine code.
(2) Requires the definition of an Interface (OSDI) and a Ngspice implementation that interacts with the interface.

In the last few weeks we have improved some small details in the OSDI documentation/examples (attached)
and also implemented a first version of the interface's counterpart into Ngspice.
For checking and developing the interface, we currently use a hand-written diode model.

Our prototype is now able to perform AC, DC and transient simulations with this diode.
We would kindly ask you to check the implementation using the attached code. 
Please give us feedback if you have ideas for improving the implementation. 
Keep in mind, the interface is intended to also be suitable for other simulators. 

GENERAL OSDI MODEL USAGE

First, the OSDI model is compiled using the following commands:

	gcc -c -Wall -fpic diode_osdi.c -ggdb
	gcc -shared -o diode_osdi.so diode_osdi.o -ggdb

Ngspice scans "/usr/local/share/ngspice/osdi" for compiled shared objects and the "./osdi" folder in the current working directory.
Therefore you need to place the resulting shared object file in one of these folders.

In a netlist, the OSDI model is activated as follows:

model definitions:
.model dmod_built_in d( bv=5.0000000000e+01 is=1e-13 n=1.05 thermal=1 tnom=27 rth0=100 rs=5 cj0=1e-15 vj=0.5 m=0.6 )
.model dmod_osdi osdi diode_va (rs=5 is=1e-13 n=1.05 Rth=100 cj0=1e-15 vj=0.5 m=0.6)

*OSDI Diode:
A1 D 0 T dmod_osdi

*Built-in Diode:
*D1 D 0 T dmod_built_in

The letter "A" has been reserved for OSDI. Hence, we must compile Ngspice at this time without XSpice, because all other letters are reserved.
In the future we do not want XSPICE and OSDI to be exclusive. Do you have a better solution here?

RUNNING OUR EXAMPLE AND UNDERSTANDING THE CODE

We have attachted our changes as a git patch file. You can apply this to the latest master branch (ngspice-36) with

> git am <PATHFILE>
    
Alternatively we have also sent Dietmar and Holger an invitation link to our private fork of ngspice.
You can then compile NGSPICE as usual but as mentinoned above you need to ensure that XSPICE is disabled.

Some small parts of the prototype (iterating directories and opening shared object files) is platform specific code. For now the implementation can only be compiled on unix. Windows support will be added once everything else is working
(should be fairly easy).

The prototype is implemented in src/spicelib/devices/osdi. 
For each OSDI compact model found in the loaded shared libraries a new SPICE device is created.
The static information like parameters names/types are populated into the SPICEdev struct.
Additionally a generic implementation of the various SPICE functions (load, setup, ..) are also added.
When these generic functions are called they can use the GENmodType field to find the descriptor they belong to.

Currently transient simulations take quite a few additional iterations compared to the hand-written model.
While we use a different (simpler) charge formulation in our example, we believe that this points to an oversight in
the implementation.
We suspect the cause of this problem is that we do not implement the DEVconv function. 
Could you double check this and roughly outline what functionality this function must perform?
Our understanding is that it checks convergence during transient simulations (to ensure the timestep is small enough).
Is this correct? 
    

NEXT STEPS
Once we have agreed on the interface, we will adjust the compiler so that the shared objects that are produced by it 
follow the specification. 
Then we will implement many test cases that check AC,DC and transient analysis of the CMC models.
    
The NGSPICE team can also tell us whether they prefer the current solution of loading the shared object files from a
fixed directory or if a simulator command that loads a specific shared object file would be preferable (and possible).

We have CC'ed also the Xyce team and Wladek for keeping them updated. For the time being, we will keep 
the project state limited to this small circle, until we feel have reached a state where the project is worth
publishing.
We could also set-up a meeting to discuss the implementation details.

Best regards,

SemiMod Team

