gnucap-devel
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]