subcircuits and commons

Hi Al.

On Tue, Sep 08, 2015 at 10:56:10AM -0400, al davis wrote:
> Now, I think the whole MODEL hierarchy is unnecessary baggage 
> that should be phased out.

ok, in my "subckt" branch, the MODEL_SUBCKT class has gone. i have
implemented DEV_SUBCKT_PROTO : public DEV_SUBCKT as a substitute.
the subckt commands now obtain a DEV_SUBCKT_PROTO* through
device_dispatcher["subckt"]. DEV_SUBCKT_PROTO::clone_instance returns a
DEV_SUBCKT* with itself as the _parent.

this is sufficient for my original purpose, namely plug in an
alternative "subckt" implementation.

> The ability to have behavioral models in commons (bm_*) 
> is another way to deal with different behavior for the same type 
> (SPICE levels, VHDL multiple architectures for an entity).

i have experimented with commons a bit. i think DEV_SUBCKT_PROTO could
provide a common and DEV_SUBCKT could expand from there (instead of
using _parent). i do not yet see a benefit, as long as both theses
classes, DEV_SUBCKT and DEV_SUBCKT_PROTO on top of BASE_SUBCKT are
required.

would it make sense to merge DEV_SUBCKT (the simulatable instance) into
BASE_SUBCKT, and augment BASE_SUBCKT so it will run various types of
common...?

> So perhaps all uses of MODEL_SUBCKT should become DEV_SUBCKT?

yes. currently, I (still?) need DEV_SUBCKT_PROTO on top, to turn the
simulation commands for the prototype into no-ops. anyway, lang_*
only sees BASE_SUBCKT* and DEV_SUBCKT(_PROTO) could safely move into
a plugin.

cheers
felix