subcircuits

On Tue, Sep 08, 2015 at 10:56:10AM -0400, al davis wrote:
> On Monday 07 September 2015, Felix Salfelder wrote:
> > you are right about e_subckt, the distance between
> > SUBCKT_BASE and DEV_SUBCKT is small enough, and i could just
> > use the existing base. however, i still need an inheritable
> > MODEL_SUBCKT. do you agree? i will prepare another patch..
> 
> sort of.
> 
> Before the use of the dispatcher, I would have agreed 
> completely.  I considered it, but got distracted to make the 
> dispatcher system and plugin system.
> 
> Now, I think the whole MODEL hierarchy is unnecessary baggage 
> that should be phased out.  It's a remnant of SPICE.  The 
> uninstantiated static element that is cloned substitutes for the 
> MODEL.  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).
> 
> So perhaps all uses of MODEL_SUBCKT should become DEV_SUBCKT?

ok. MODEL_SUBCKT and DEV_SUBCKT implement similar things, so somehow
this makes sense. the crucial difference is, that MODEL_SUBCKT overrides
is_device(), which returns false, and has several no-ops for simulation
relevant functions such as ::expand().

do you suggest that functions such as BASE_SUBCKT::expand() should ask
common()? i can think of something close or similar to
BASE_SUBCKT::expand() { common()->expand(this); } behind the scenes, so
the rest of the code will only see BASE_SUBCKT during construction and
(whichever variant of) DEV_SUBCKT during analysis.

thanks
felix