[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 

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]