[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] ELEMENT interface question
From: |
al davis |
Subject: |
Re: [Gnucap-devel] ELEMENT interface question |
Date: |
Tue, 20 Nov 2012 16:23:23 -0500 |
User-agent: |
KMail/1.13.5 (Linux/2.6.32-5-amd64; KDE/4.4.5; x86_64; ; ) |
On Tuesday 20 November 2012, Felix Salfelder wrote:
> my impression is that ELEMENTs are intended to be stateless,
> at least apart from minimal simulation specific data (times,
> matrix entries, some history).
ELEMENT is a base class. There are no instances of ELEMENT.
You can put all of the state info you need in your device, which
inherits from ELEMENT.
Alternatively, you might consider inheriting from STORAGE
instead. It has state info.
> three examples for behavioural models need to store extra
> data. a switch needs to know its state and switch time, the
> controlled oscillator needs to know its phase, and
> IR-filters need to stash their history. currently, this is
> crudely worked around in the filters, and appearantly a bug
> in the oscillator (bm_switch doesn't exist yet).
The "bm" functions are a throwback to trying to do some notion
of behavioral modeling within a spice syntax. They don't let
you define new devices, just to embellish existing ones, such as
a nonlinear or temperature dependent resistor. It's still a
resistor. A resistor is a two terminal device defined by v =
f(i), without storage.
Looking forward, I think it is best to think of this as
depricated. We should be thinking Verilog-A for new devices,
and real new devices. Not trying to turn resistors into
oscillators.
I doubt if bm_switch will ever be part of the main line. The
bm_ files are designed as plugins, so there is nothing stopping
you from trying, as a plugin.
> imho, giving up those (potential) models would be too bad, so
> ELEMENT needs to be enhanced somehow. i'd like to give it a
> try, if you haven't already worked out something. ideas,
> objections, warnings are welcome.
That set of base classes (COMPONENT, ELEMENT, STORAGE) are just
base classes. Whatever is there you could duplicate in every
device, but shouldn't. They are provided to reduce the amount
of new code you need, and to force some commonality.
Spice does not have this. Instead, all that code is duplicated
over and over.