pPar to be used with float or int parameters

  • Thread starter Thread starter Frédéric BATTIN
  • Start date Start date
F

Frédéric BATTIN

Hello,
I'm using the pPar() function for a specific macro device, and to be
able to netlist parameters through the hierachy. Also parameters
coming for one level up .
It is working fine with " string parameters" but not with float or
integer !
Do you have any idea ? How can I manage such non-string parameters /
thanks for your help ,
Fred
 
Salut Fred,

Nice to see on-board and I'm very pleased to contribute your question
even though I find a bit tricky.
First of all, I quite don't understand why the pPar() breaks for non
string parameters at your side. Besides, you don't disclose which
simulator you are aiming to netlist for. I'm assuming spectre for the
purpose of this thread even tough I'm pretty much sure you are running
Eldo.
Anyway, I have just created a quick testbench where I passed pPar()
expressions to 3 of the user parameters as following:
1. W= pPar("myW") --> Defined as float in the cdf
2. L=pPar("myL") --> Defined as string in the cdf
3. M=pPar("myM") --> Defined as Int in the cdf.

I have re-created the symbol and then Created a testbench for it.
I have assigned values to the above paramers on the symbol and my
simulation ran pretty well.

My Spectre netlist looks like:

// Library name: rkWorkLib
// Cell name: rkInv
// View name: schematic
subckt rkInv VDD VIN VOUT VSS
parameters invW invL invMult=1
M1 (VOUT VIN VDD VDD) gpdk090_pmos2v w=3*invW l=invL m=invMult
M0 (VOUT VIN VSS VSS) gpdk090_nmos2v w=invW l=invL m=invMult
ends rkInv
// End of subcircuit definition.

// Library name: rkWorkLib
// Cell name: tb_rkInv
// View name: schematic
V2 (vin 0) vsource dc=VPLUS type=pulse val0=VPLUS val1=0 period=100n \
delay=2n rise=2n fall=2n width=50n
V0 (net11 0) vsource dc=0 type=dc
V1 (vdd! 0) vsource dc=VPLUS type=dc
I2 (vdd! inv23 vout net11) rkInv invW=50u invL=3u invMult=3
I1 (vdd! inv12 inv23 net11) rkInv invW=15u invL=1u invMult=2
// remaining netlist ...
// -------------------------------------------------------

Well, I have demonstrated a one-level up only. one may try one more
level to double check this but here is my question now: Why do you
want to use non-strings ? this is very likely to give you some hassle.
In fact, pPar() only passes information 1 level up the hierarchy so if
your design has multiple levels, you will need to create multiple pPar
() to pass info to the top level. And to do so, you parameters need to
be defined as pPar() because you would not be able to pass a pPar()
expression into a int/float field. In addition if you want your
netlisting to be portable to other tools like AMS designer, you also
need to assign the attributes parseAsNumber and parseAsCEL
(parseAsNumber must be used when parseAsCEL is yes). parseAsCEL=yes is
necessary for the parameter to be processed as a CEL expression, i.e
usable with pPar()

That was my attempt and hope it is helpful, at least to trigger the
discussion around this topic.
Having said that, I'm wondering whether I'm missing something you
might wanted to spot ...
Any details are more than welcome !

A+
Riad.
 
Riad KACED wrote, on 06/25/09 23:47:
Salut Fred,

Nice to see on-board and I'm very pleased to contribute your question
even though I find a bit tricky.
First of all, I quite don't understand why the pPar() breaks for non
string parameters at your side. Besides, you don't disclose which
simulator you are aiming to netlist for. I'm assuming spectre for the
purpose of this thread even tough I'm pretty much sure you are running
Eldo.
Anyway, I have just created a quick testbench where I passed pPar()
expressions to 3 of the user parameters as following:
1. W= pPar("myW") --> Defined as float in the cdf
2. L=pPar("myL") --> Defined as string in the cdf
3. M=pPar("myM") --> Defined as Int in the cdf.

I have re-created the symbol and then Created a testbench for it.
I have assigned values to the above paramers on the symbol and my
simulation ran pretty well.

My Spectre netlist looks like:

// Library name: rkWorkLib
// Cell name: rkInv
// View name: schematic
subckt rkInv VDD VIN VOUT VSS
parameters invW invL invMult=1
M1 (VOUT VIN VDD VDD) gpdk090_pmos2v w=3*invW l=invL m=invMult
M0 (VOUT VIN VSS VSS) gpdk090_nmos2v w=invW l=invL m=invMult
ends rkInv
// End of subcircuit definition.

// Library name: rkWorkLib
// Cell name: tb_rkInv
// View name: schematic
V2 (vin 0) vsource dc=VPLUS type=pulse val0=VPLUS val1=0 period=100n \
delay=2n rise=2n fall=2n width=50n
V0 (net11 0) vsource dc=0 type=dc
V1 (vdd! 0) vsource dc=VPLUS type=dc
I2 (vdd! inv23 vout net11) rkInv invW=50u invL=3u invMult=3
I1 (vdd! inv12 inv23 net11) rkInv invW=15u invL=1u invMult=2
// remaining netlist ...
// -------------------------------------------------------

Well, I have demonstrated a one-level up only. one may try one more
level to double check this but here is my question now: Why do you
want to use non-strings ? this is very likely to give you some hassle.
In fact, pPar() only passes information 1 level up the hierarchy so if
your design has multiple levels, you will need to create multiple pPar
() to pass info to the top level. And to do so, you parameters need to
be defined as pPar() because you would not be able to pass a pPar()
expression into a int/float field. In addition if you want your
netlisting to be portable to other tools like AMS designer, you also
need to assign the attributes parseAsNumber and parseAsCEL
(parseAsNumber must be used when parseAsCEL is yes). parseAsCEL=yes is
necessary for the parameter to be processed as a CEL expression, i.e
usable with pPar()

That was my attempt and hope it is helpful, at least to trigger the
discussion around this topic.
Having said that, I'm wondering whether I'm missing something you
might wanted to spot ...
Any details are more than welcome !

A+
Riad.
Click to expand...

In general, I'd say that pPar() can only be used on a CDF parameter which is a
string and has parseAsCEL set to "yes". This is because if the CDF parameter is
a float, then you can't enter the text for the pPar(). It may be that in Riad's
case he changed the CDF to float after entering the pPar() expression, and so
the instance property is actually a string, despite the CDF being defined as a
float.

The parseAsCEL is needed because this is an expression, and so needs to be
interpreted.

In some netlisters you can get away without parseAsCEL because they tolerate
incorrect CDF. But in others this will cause trouble...

Andrew.
 
First of all, thank you very much Riad and Andrew.

It is clear now for me how it is going one.
I need string and parseAsCEL() yes ..

In fact it was for spectre, withing a macro mos who instanciate an
other mos !
Let me clarify :
I have a macro-mos and a mini-mos . The mini-mos is instantiate in
the macro-mos with pPar for W, L and all needed parameters.
Unfortunately, mini-mos is having float, without parseAsCEL ...

The first idea I had was to add to the instance some local parameters
with iPar,... but it is not working well. CDF parameters are the one
to be use.
My second idea, is to overwrite baseCDF with userCDF loaded
in .simrc , where string type and parseAsCELL=Yes will be set.
I'm now doing some tests, and keep you inform ...
regards,
Fred
( I'll be on vacation for 1 week, and will be back to W928 ! )
 
You must log in or register to reply here.

Latest threads

Back
Top