Re: [Gnucap-devel] problem with clone_instance

[al davis]

On Sunday 17 November 2013, Felix Salfelder wrote:
> > This part of spice syntax doesn't have a counterpart in
> > verilog  syntax.
> 
> yes. what do you suggest? raise an exception? i do not care
> too much, but it should not segfault :)

Immediately, my suggestion followed in that same email.

An assert in the code is documentation of some condition that is 
assumed to be true.  An assert fail is not a bug in itself, but 
rather a hint at where the bug really is.

In this case, _component_proto needs to be initialized non-NULL 
by a constructor.  See other code such as the device models, 
d_switch, or d_logic.


Longer term, it raises another issue that I have been aware of 
for a long time but don't have the answer yet.

The other issue here is that there is a bug in a plugin that 
causes an assert fail in core, indicating a need for a change in 
strategy.  A lot of the asserts in core should be considered as 
possible user errors, if you think of developing plugins as a 
user activity.

Developing plugins really is a user activity.  When we get our 
act together on the model compilers, gnucap could become the 
preferred platform for developing and debugging device models 
regardless of the target simulator.

Stroustrup discusses this in "The C++ Programming Language".  I 
see it moving in that direction.

The problem with changing all of the asserts is that there would 
be a significant performance hit. 

> 
> > It is not a link back to the kind of device it matches, so
> > that  code is incorrect.
> 
> agreed.
> 
> > The real problem is that the constructor MODEL_SEMI**** is 
> > defective, so it should be fixed there.  The purpose of 
> > _component_proto is exactly this, so the constructor must 
> > initialize it.
> 
> hmm which value for _component_proto would be correct? if i
> don't want an unconditional resistor, then i will have to
> catch the null pointer somewhere within MODEL_CARD.

See the other models to see how it is done there.

I think this is the only one that is unclear.  In others, one 
DEV can have many MODELs.  For example .. levels of mosfets.  
But I think this is the only one that goes the other way.