Re: parameter scopes for subckt instances

al davis <[email protected]>
Newsgroups gmane.comp.gnu.gnucap.devel
Message-ID <[email protected]>
On Thursday 18 October 2012, Felix Salfelder wrote:
> playing with spectre netlists i came across a small issue
> about parameter scopes in subdevice instances.

I agree to make it spectre compatible.

I see a couple of issues, and solutions to them.

1.
On Thursday 18 October 2012, Felix Salfelder wrote:
> replace the call
>   subckt()->precalc_{first,last}();
> 
> with
>   assert(!_parent->subckt()->params()->_try_again);
>   _parent->subckt()->params()->_try_again =
> (scope()->params()); subckt()->precalc_{first,last}();
>   _parent->subckt()->params()->_try_again = 0;

I don't like the idea of tampering with the "_parent", then 
untampering it ..  (although I did just that in spice_wrapper, I 
couldn't figure out another way) ..

Instead, how about a second _try_again in u_parameter?  Call it 
"_try_again_2".

2.
Regarding "precalc_{first,last}" ...

_parent is not known for sure in _precalc_first.  _parent is set 
in expand, and _precalc_first is called before expand.  On the 
first pass, _parent is known to be not known.  On later passes, 
it retains a value from before.  It is best to assume that 
_parent is never known.

That is the reason for having both precalc_first and 
precalc_last.  In some cases, the behavior of expand can depend 
on parameters.  These must be evaluated in precalc_first.  In 
other cases, parameter settings can depend on what happened in 
expand.  These must be evaluated in precalc_last.  These two 
concepts are mutually exclusive, so any parameter should be 
evaluated in one or the other. In some cases, it doesn't matter.

This too suggests a second _try_again.


If there is a conflict, who wins?

parameters volts=2
subckt compon (1 2)
   V1 (1 2) vsource dc=volts
ends

subckt deeper (1 2)
   parameters volts=3
   inst1 (1 2) compon
ends

instance1 (1 2) compon
instance2 (2 3) compon volts=4
big1 (3 4) deeper
big2 (4 5) deeper volts=5
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.