gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] parameter scopes for subckt instances


From: Felix Salfelder
Subject: Re: [Gnucap-devel] parameter scopes for subckt instances
Date: Sun, 21 Oct 2012 01:56:04 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

Hi Al, hi list.

On Fri, Oct 19, 2012 at 12:29:17AM -0400, al davis wrote:
> I agree to make it spectre compatible.

there are probably similar issues in verilog and spice. lets fix it...

> I don't like the idea of tampering with the "_parent", then 
> untampering it 

that was a quick hack. there must be some clean way to implement it.
(and it didnt even work very well.)

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

i think it isnt as complicated as that. _try_again_2 looks like a tree of
scopes is intended. imo the scope order is strictly linear.

> 2.
> Regarding "precalc_{first,last}" ...
> [..] 

that really helped. thanks.

> 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

i expect
instance1: 2
instance2: 4
big1: 3
big2: 5

the evaluation order for a subdevice instanciation should be (in my
understanding):
1. parameters that are passed as arguments
 (like in "instance2 (2 3) compon volts=4")
2. parameters that are computed/assigned within the subckt declaration
3. parameters in the scope containing the device instance.
(4. the parameters in the scope containing the sckt declaration dont need to be
         considered because they are reachable from the scope containing the
    instance)

this can be achieved by copying the model parameters to the instances,
and lining them up between subckt()->params() and scope()->params().
because an actual copy is bad, i've implemented this by splitting up PARAM_LIST
into PARAM_LIST_MAP (the actual map) and PARAM_LIST_COPY (something that
behaves like a copy of it). both inherit from PARAM_LIST_BASE.

all of this is happening in u_parameter.*. from the DEV_SUBCKT::expand
implementation the evaluation order is now obvious (which i think is
important):

"""
  PARAM_LIST_MAP* pl = const_cast<PARAM_LIST*>(model->subckt()->params());
  _params = pl; // calls PARAM_LIST_COPY::operator=
  subckt()->params()->set_try_again(&_params); // 2.
  _params.set_try_again(scope()->params()); // 3.
"""

you can find this in the 'spectre' branch on tool. i havent yet cleaned up or
tested the code very much. also there are set_try_again kludges in
precalc_{first,last}, that finally shouldnt be necessary. my netlist (including
nested models and subckts) and the demonstration similar to your example (see
tests/spectre_subckt.gc) work.

regards
felix



reply via email to

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