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. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
