some replies first


To ng-spice@ieee.ing.uniroma1.it,ng-spice-devel@ieee.ing.uniroma1.it
From Francesco Doni <f.doni@ieee.org>
Date Tue, 25 Apr 2000 23:41:27 +0200
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To <0003211340140G.00802@yaesu.ada-works.com>
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
Reply-To ng-spice-devel@ieee.ing.uniroma1.it

 Hello everybody,
Sorry, it's a long time since my last mail, please understand me.
I spent some time trying to make sense of spice internals while
thinking to some possible scheme concerning its open structure.
I prepared few posts today, I hope that they will be delivered to the list!
Now some replies, in the next one the promised ideas summary.

Contribute by Stephen Tell:
>To sumarize, it sounds like you are talking about a sort of "interpreted"
>models in addition to compiled models.  In the commercial spices, one can
>usually do somthing of this sort using subcircuits that contain various
>predefined models (resistors, etc) and dependent voltage or current
>sources that are controlled by arbitrary arithmetic expressions involving
>constants and voltage/current measurements at other nodes.     I don't
>think a new language is necessary to implement your idea.
>
>Implementing these expression-controlled sources in a compatible way would
>be a start.  For greater utility, two enhancements come to mind.
>
>1. The ability to map a model name or mosfet  model-level-numer into such
>a subcircuit.  I think this could be mostly an internal syntactic
>transformation.  It would let you continue to use for
>example "m" mosfet elements while implementing the model as a
>subcircuit.
>
>2. table-lookup and other programming-language-like functions alongside
>the traditional built-in arithmetic operations.
>
>3. APIs and utilities to ease the pain of transforming such
>subcircuit+arithmetic based models into C for compilation.

Contribute by Paolo Nenzi:
>I think that Francesco wants to do something like XSPICE compiled model
>support. You write a model with equations in C (e,g.) using a set of
>extension api. The model may be eventually written in C and interpreted by
>a C interpreter and only after debug process compiled. Franz ?

Well I don't know many commercial spice implementations like the one
mentioned, so please be patient if some solution already exists, if possible
give me some reference of software and tools time by time mentioned
in ng-spice mailing lists. I posted in February an in depth reply but it 
seems lost
in the network, I don't  remember all details indeed I hope to explain the 
concept herein
while giving a comprehensive review in the summary mail.
My purpose and what I tryed to do few years ago is to address the problem
to make the addition of new portions to spice an easy task, regardless their
nature of optimization modules or function and of new models for new process
such as nanotechnology or direct silicon access like models.
Steve and Paolo in one way or another are both right. I don't mean 
"interpreted"
models in addition to compiled models but a facility to build compiled models
and a facility to add binary modules to spice regardless they are models or 
other things.
A model is something like a subcircuit with some arithmetic addition and 
process
information as physical parameters, so I think, as well, that a new language 
is not necessary
I would use the same "circuit description schema" I drafted in some mail to
improve the netlist readability (suggesting solutions like structuring and 
templating)
in which could be implemented for instance a C code generator in order to 
convert
a subcircuit in a compile-able module.
I used something like that several years ago to describe finite state machines
in a as general as possible language i.e. I used the concept of graphs,
since a circuit is made of ideal components to which we add parasitic
and actual behavior all expressed in a graph form, we need only to
introduce graph capable interface to the spice kernel overcoming the netlist,
this is exactly I have done with FSM problem, this interface would be useful
both to describe the circuit for simulation or optimization purpose and to 
define
new models.


Contribute by Jan Vercammen:
>> -3- [snip] Personally I would suggest that
>>     the ng-spice team should draw up a specification of the kernel code 
>interface,
>>     which could address:
>>      - a minimal and efficient syntax/grammer for the input specification 
>(input string)
>>      - address multiprocessing issues (for efficient monte carlo analysis, 
>sweep , ...)
>>      - error reporting
>>      - output vector structures

Contribute by Reid van Melle:
>[snip] It would
>be nice if the input specification divorced itself from Spice netlists.  A
>circuit is really a graph structure which is how it is represented internally
>in Spice.  Parsing a spice netlist is basically a conversion of a textual
>version of the graph to a binary representation.  If there was a generic
>circuit/graph building interface on Spice, then input circuits could be 
>entered
>directly from a schematic entry tool, from a standard Spice netlist, or an
>XML-based format.
>
> -4- [snip] It may be easier to use spice3f5 as a starting point and try to 
>migrate
>towards a new simulator:
>- develop a library version of spice with a well-defined interface for
>front-ends and back-ends
>- break off pieces of the simulator into well-defined components.  It is
>possible to migrate a C code base to a C++ code base by slowly breaking off
>modules.

I completely agree with the above considerations made by Jan Vercammen
and Reid van Melle. I believe that a specification draft should be done as 
soon
as possible and I would ask you to contribute with your software expertise.
One of my problems is to get the overall effort on ngspice and what's going 
on.
In the past years I developed around Berkeley spice some of the ideas I 
presented
within this mailing list but now it seams not an easy task to integrate my 
code into ng-spice.
A specification could solve many problems in order not to waste time.

The structuring problem was one of the subjects of my previous post
not limited to the spice code but also models, netlist and interfaces,
actually Paolo is still working on this issue while coding ng-spice.
The concept of graphs was exactly in my mind while I was writing about
the netlist readability, suggesting solutions like structuring and templating.
The netlist circuit/graph building interface on Spice is the actual 
improvement
and what I considered essential for the web based design process I was 
pursuing.
The other side of the coin is backward compatibility, many people look at this
and defining a draft we should take into account these aspects, anyway 
computing
modules should be structured in independent libraries with a well designed 
interface.
I believe that a lexical analyzer and a parser with an improved error 
handling system
(futures like compilers), could easly transalte the netlist into a graph 
description.
For this purpose i suggest lex and yacc tools.

Contribute by GLAO S. Dezai:
>The idea is to handle all the messages (errors, warnings, etc...) in a 
>similar way.
> 1. Writting a single error displaying routine for the entire simulator
> 2. Writting a single file where the strings array will be put.
> 3. Carefully  identifing and numbering all the simulator's messages in 
>relation with the
>string table

To this end I strongly agree with the idea of unified error displaying and 
handling
routine for the entire simulator, but I suggest to consider the possibility to
live the software open to error messages coming from dynamic added objects
therefor the error handler module should be part of the spice kernel so each 
other
module will know it and pass its own messages, error messages should be 
embedded
in each autonomous piece of code regardless it is a model o an other function.


Franz


Partial thread listing: