Verilog-A? Re: [Ngspice-devel] Re: Ngspice-devel digest, Vol 1 #35 - 2 msgs

[Al D. <al...@ie...>]

On Tuesday 21 May 2002 08:08, Steve Hamm wrote:
> ...........   But I'd _really_ like
> to see a good public-domain implementation of Verilog-A, instead of
> a better ASRC.  This would do everything the ASRC does and much
> more...

I am aware of a VHDL-AMS from Cincinnati, but as of the last I heard 
(from Hal Carter, the professor leading it) the performance was very 
poor.  It ran much slower than Spice.

Probably the closest with reasonable performance is the Gnucap model 
compiler.  It is a somewhat lower level than Verilog-A.  It is more 
C-like.  The goals are run time efficiency, so it can be used for the 
mainstream models without taking a performance hit.  All of Gnucap's 
semiconductor models are now coded with it.  Actually, there is a lot 
more in it than Verilog-A has, and there is more to come.  At some 
point, with some syntax changes, it will be reasonable to make a 
Verilog-A compatible subset of the language.  The most important 
feature that is missing is automatic differentiation.

If someone wants to make a back-end for NG-Spice, and help to 
generalize the language, that would be much appreciated.  It won't be 
easy!

Verilog-A alone is not adequate for the task.  There is a need to set 
up probes, indicate what can be shared, bypass and queueing criteria, 
precalculation of some data, and others.  To not address this would 
mean a significant sacrifice in performance or usefulness in the 
future as simulator capability hopefully improves.

Back to the ASRC ....   I have some code to optimize the expressions, 
down to a reduced complexity expression using a mix of tables and a 
stack oriented interpreter.  I did it partly as part of IBIS support, 
and partly for generalized expressions in Gnucap.

Another feature that would be useful is a standardized interface to 
external executable models.  They could communicate through some kind 
of pipe, so the external model could be written in any language that 
produces an executable file.  This opens up tools like octave for 
model development.  There would be a significant performance hit, but 
it would add significant capability that doesn't exist now.  A 
significant challenge here is to do it in a way that does not cripple 
the simulator, or lock you into old algorithms and block improvements.