[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 00:34:10 -0500 |
User-agent: |
KMail/1.13.7 (Linux/3.2.0-4-amd64; KDE/4.8.4; x86_64; ; ) |
On Saturday 16 November 2013, Felix Salfelder wrote:
> bmm_semi.cc defines two MODEL_CARDs with no _device_proto.
I assume you mean _component_proto.
> this is a problem in
>
> verilog
> res X(1,2);.
That statement is ambuguous.
Consider spice mode. You are assuming it means the same as
this, except for the device name.
R4 (1 2) res
But that is not always true. It could be:
V1 (1 2) res
C1 (1 2) res
or a variety of others.
This part of spice syntax doesn't have a counterpart in verilog
syntax.
It is the same idea as:
v1 (1 2) pulse ...
i1 (1 2) pulse ...
or with acs/gnucap extensions:
r1 (1 2) pulse ...
The name of the model does not define the base device.
> res is a model, which is found by find_proto and
> LANGUAGE::new__instance unuspectingly calls clone_instance.
> here assert(_device_proto) fails.
>
> there ara multple ways to fix it. my favourite is something
> like this.
>
> CARD* MODEL_CARD::clone_instance() const
> {
> if (_component_proto) {
> return _component_proto->clone();
> } else if( const CARD* c = device_dispatcher[dev_type()] )
> { return c->clone();
> } else { unreachable();
> throw Exception("cannot instanciate");
> }
> }
>
> (make sure dev_type is "resistor" and "capacitor" accordingly
> in bmm_semi.cc. the dispatcher wont find "r" or "c" in case
> sensitive mode.)
dev_type in a model is its own name, used by print_paramset to
print the name of the master (spectre terminology) or parent
(what it started out as a clone of).
It is not a link back to the kind of device it matches, so that
code is incorrect.
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.
For some time I have been questioning the whole MODEL_CARD
hierarchy as redundant. It is a hangover from the spice design,
and the old ACS design before any use of plugins, before the
notion of "clone" was implemented, before the use of an
uninstantiated instance as a prototype.
Spice needed the separate hierarchy for efficiency, so complex
devices with many parameters could save memory by having many
instances of a model. Also, so there can be (in VHDL
terminology) multiple architectures (such as model levels) for
an entity. Gnucap doesn't need this in this way because the
COMMON accomplishes the same and more. Also, it doesn't really
fit the other source formats like spectre and verilog. The
verilog paramset is more flexible than the spice model. Verilog
really makes no distinction between model and device parameters.
Gnucap can support this with better efficiency with hierarchical
commons.
I think for the future we should consider eliminating the
MODEL_CARD hierarchy completely.
- [Gnucap-devel] problem with clone_instance, Felix Salfelder, 2013/11/16
- Re: [Gnucap-devel] problem with clone_instance,
al davis <=
- Re: [Gnucap-devel] problem with clone_instance, Felix Salfelder, 2013/11/17
- Re: [Gnucap-devel] problem with clone_instance, al davis, 2013/11/17
- Re: [Gnucap-devel] problem with clone_instance, Felix Salfelder, 2013/11/18
- Re: [Gnucap-devel] problem with clone_instance, al davis, 2013/11/24
- Re: [Gnucap-devel] problem with clone_instance, al davis, 2013/11/24
- Re: [Gnucap-devel] problem with clone_instance, Felix Salfelder, 2013/11/25