Re: ELEMENT interface question

Hi Al, hi list.

On Tue, Nov 20, 2012 at 04:23:23PM -0500, al davis wrote:
> 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.

the devices in question are already implemented, and wont store anything
bm-related. the point is, i like the idea of having a behavioural model
that is plugged into one of the ELEMENTs. like having a filter,
oscillator, whatever and _then_ decide whether it's going to be plugged
into a vcvs or vccs etc.

> Alternatively, you might consider inheriting from STORAGE 
> instead.  It has state info.

for this i'd still have to implement new COMPONENTs.

> 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.

thats understood. but why should that be limited to spice? in verilog
something similar to

somefilter #(type=fir, coeffs=(1,2,3)) vcvs(a,b,c,d);

should be possible/might already work in -uf (after some set_parameter_*
hacking).

> 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.

va isn't there yet. and even if i made the vco compile with admsXml (a
question of hours), it probably would still not do the sampling right.
also it couldn't be plugged into the different 4-poles...
while va is great to write down transistor models, ELEMENT+BM is way
smarter than anything verilog can do, (but that's my opinion.)

> 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.

as the built-in switch device didn't work for me once (zero transition
time...), bm_switch seemed to be the way to implement it. imho it is a
good idea to have plugins outside the main line. that's what gnucap-conf
is for.

> 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.

dont reduce bms the code (relative to all variants of bm+ELEMENT) much
more? i can even reuse the filters to implement noise sources...

regards
felix

PS: so, even if it's not intended, i guess that a state inside a bm must
simply be mutable. i doubt there's a problem with it, as long as
operator== returns false.