Re: precalc_first

[Felix Salfelder]

On Fri, Apr 09, 2021 at 08:26:52PM -0400, al davis wrote:
> It has to do with the interaction between precalc and expand, and

Thanks Al. Much clearer now.

> Calculations that may have an impact on expand (structure) must be
> done in precalc_first.  Calculations that depend on how expansion was
> done must be done in precalc_last.

If it wasnt for the case below, why is precalc_first not done in expand?
(Is it speed again?)

> That looks like a problem with print_test in the .model files, or the
> generated code in XXXXXX::param_is_printable() .
> save_list probably should not call precalc_first.  What about
> precalc_last ? ..  or maybe it should.  print_test depends on it.

Omitting precalc_first does break print_test. But also final_default,
e.g. mjsw in d_mos5. The substitution good->hard will only recover a few
of them, and not sure if there is a workaround at all.

> I suppose precalc doesn't hurt anything.

Finally, the use in c_list looks legitimate. "Adjust the appearance in a
netlist" or so.

> So maybe precalc_first and precalc_last should not be disabled in
> DEV_SUBCKT_PROTO.

Ok I tried (see git). Some remarks.

- It seems DEV_SUBCKT_PROTO::precalc_first must omit
  DEV_SUBCKT::precalc_first, in order to avoid wrong values in the
  parameter map. (attach_params side effects).

- The additional subckt()->precalc_first triggers a few extra "using
  default" warnings. I expected some, but I see twice as many in
  d_subckt.{7,8}.ckt.

- I cannot see the use for precalc_last there. precalc_last comes after
  expand, and expand is already disabled. I did not touch it.

cheers
felix