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
_______________________________________________
Gnucap-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnucap-devel
