[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] problem with clone_instance
From: |
al davis |
Subject: |
Re: [Gnucap-devel] problem with clone_instance |
Date: |
Sun, 17 Nov 2013 14:33:43 -0500 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) |
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.