I have used the pPar("my_parameter") approach to define parameters in subcircuits I wanted to instantiate on a higher level.
One simple example would be a parallel RLC whose element values are calculated by using Q factor, resonance freq, impedance level.
I have done this type of things with elements from the analogLib several times, so I guess that the procedure is correct.
I have tried lately to parametrize a cell with transistors from the PDK we use for our chips, and I am encountering a very fuzzy behavior. I start from scratch and add first one passive element - a MOM capacitor - and define all parameters to be inherited as pPar(..), like metal spacing, width, number of vertical fingers etc...
After editing the CDF, I can simulate, no problem.
Then, I add an NMOS, various parameters, edit CDF, simulate. Again, no problem.
A PMOS, same story, simulate, perfect.
Then, I add some more transistors, and use the same labels for those whose sizes must match. That is, if I define the finger width to be pPar("fw_n") for the NMOS and I have two transistors which should have equal widths, in the second transistor the finger width will again be defined as pPar("fw_n"). Well...at this point, things go wrong. The generated netlist is flawed. I get errors like:
ERROR (SFE-874): "input.scs" 46: Unexpected real number "00.0". Expected close parenthesis.
ERROR (SFE-709): "input.scs" 46: No master specified for instance `exp'
I can get any sort of this errors...expected this, expected that.
The crazy thing is that if I now delete the transistors that 'caused' the netlist to fail...The new netlist fails nevertheless!! Once this effect happens, there is no turning back. Unless I take ALL transistors out of my cell. If I dare to put back one - the same configuration I had and which worked - the netlist fails.
To my non-expert eye it looks like the transistor parameters like drain area and such, which are functions of other transistor sizes which I parametrized, are maybe written in a way that causes problems...But I cannot dig deeper than that.